Personnaliser les MapTips d'ArcGIS Server - 1/4

Lors de la création d'applications web avec ArcGIS Server, des questions reviennent souvent concernant la personnalisation de l'affichage des MapTips (info-bulles). Dans le Web ADF d'ArcGIS Server 9.2, les MapTips permettent de présenter à l'utilisateur une série d'informations concernant une entité en cliquant simplement dessus. Je vous propose une série de 4 articles pour passer en revue les différentes aspects de la personnalisation de ces MapTips.

Modifier le contenu des MapTips

La définition du contenu des MapTips est une fonctionnalité standard du Web ADF d'ArcGIS Server. Pour cela, vous devez utiliser votre environnement de développement (Visual Studio 2005 pour le Web ADF .Net).

1) Si nécessaire, ajouter un Web Control de type MapTips dans votre page

2) Spécifier la carte (Map) à laquelle seront associés ces info-bulles.

3) Définir le service de carte (MapService) et la couche (Layer) constituant la source des info-bulles.

4) Rédiger ensuite l'expression de l'en-tête (header) des info-bulles.Dans notre exemple, le titre de la fenêtre d'info-bulle contiendra l'emplacement et la commune du PAV (Point d'Apport Volontaire).

5) Rédiger également l'expression du corps (body) des info-bullesDans notre exemple l'attribut {REFERENCE} est utiliser pour définir en partie le nom de la photo à afficher. L'expression du corps de l'info-bulle peut contenir toutes les balises HTML permettant la mise en forme de vos informations (y compris des images ou des liens).

Vos info-bulles peuvent maintenant s'afficher. Il suffit de compiler l'application Web et de l'exécuter dans un navigateur. Vous remarquerez que pour l'instant le style d'affichage est style par défaut, nous verrons comment le modifier dans le prochain épisode.

Applications ArcGIS Server de nouveau en ligne

Au mois de novembre 2007, je vous avais présenté différents aspects d'ArcGIS Server concernant la publication de services web 2D et 3D. En partant de l'exemple des collections de cartes de cartes de Cassini, je vous avais montré pas à pas les points suivants:
- la création et la publication de services de cartes 2D avec des caches et leur consommation dans une application Web (voir l'article)
- la création et la publication de services de cartes 3D et leur consommation dans ArcGIS Explorer (voir l'article)
- la publication de services de cartes 2D en WMS et leur consommation dans une application basée sur OpenLayers (voir l'article)

Ces articles sont illustrés par applications en ligne. Malheureusement, ces applications ont été indisponibles durant quelques semaines pour des raisons de logistique interne sur les serveurs de démo d'ESRI France. Juste un petit mot donc pour vous signaler que tout cela est désormais réglé et que ces applications sont de nouveau opérationnelles.

Géotraitements - N°8 : Etre informé de la fin de l'exécution

Nous terminons aujourd'hui notre première série d'articles sur les géotraitements. Notre modèle est désormais opérationnel et suffisamment générique pour s'appliquer à différents jeux de données. Dans le cas d'une exécution de notre modèle sur un poste déporté ou sur un volume important de données, il peut s'avérer intéressant d'être prévenu par email de la fin de son exécution. Envoyer un email n'étant pas un outil de géotraitement fourni en standard dans ArcGIS, nous allons détailler l'ajout de cette fonctionnalité.


Envoyer un email dans un géotraitement

Nous allons donc faire évoluer notre modèle pour y ajouter un outil qui sera chargé d'envoyer un email. Pour cela, nous allons utiliser un script Python que l'on ajoutera en tant qu'outil dans ArcToolBox puis dans notre modèle. Ce script sera placé à la fin du modèle de géotraitement et indiquera donc la date et l'heure de fin d'exécution de celui-ci.

1) Télécharger le fichier ZIP contenant le script Python suivant puis décompresser le dans le répertoire de votre choix. Une bonne stratégie est de le placer dans le répertoire C:\Program Files\ArcGIS\ArcToolbox\Scripts

2) Créer un nouvel outil dans votre ToolBox à partir de ce script. Vous définirez les 3 paramètres suivants :

- Nom du modèle de géotraitement (de type string)
- Adresse du serveur SMTP à utiliser pour l'expédition des emails (de type string)
- Adresse email du destinataire (de type string)

3) Une fois l'outil ajouté dans votre ToolBox, vous pouvez l'exécuter pour valider que vos paramètres SMTP sont valides.


Evolution de notre modèle

Il suffit donc d'ajouter ce nouvel outil à notre modèle en oubliant pas de définir une pré-condition pour s'assurer que l'outil ne s'exécutera qu'après production des résultats.

Il vous faudra ensuite renseigner les 3 paramètres de l'outil :

Notre modèle dans sa version finale ressemblera donc à ceci :



Pour vous permettre de revenir en détails sur chacune des 8 étapes de conception de notre modèle, je vous propose de télécharger la ToolBox complète.

Conclusion

Au travers d'un exemple simple nous avons illustré quelques points clés des modèles de géotraitement. Nous avons également montré comment étendre les possibilités d'un modèle avec quelques scripts Python. Nous reviendrons, dans le cadre d'une autre série d'articles, sur la publication d'un modèle vers un service web de géotraitement.

ArcGIS Explorer build 450 est disponible en français

Nous évoquions dans arcOrama il y a quelques semaines, la disponibilité de la version 440 d'ArcGIS Explorer et du supplément français correspondant. Une nouvelle version 450 d'ArcGIS Explorer a été diffusée il y quelques jours pour corriger des problèmes rencontrés par certains utilisateur ayant des cartes graphiques un peu anciennes. Comme c'est la cas à chaque nouvelle version, ESRI France vient de mettre en ligne le supplément français de la version "build 450". Vous le trouverez sur le site du support d'ESRI France à l'adresse suivante.

Géotraitements - N°7 : Packager les résultats d'un modèle

Nous continuons notre série d'article sur les géotraitements. Aujourd'hui, nous allons faire évoluer notre modèle afin que les résultats de notre modèle soient packagés (archivés sous la forme d'un fichier ZIP) pour être facilement échangeable avec d'autres utilisateurs ou plus facilement téléchargeable dans le cas d'une exécution du modèle via le web. Dans l'article précédent nous avons vu comment créer un répertoire, préalablement au découpage des couches, il nous reste donc à archiver ce répertoire.

Zipper un répertoire

Dans l'aide en ligne d'ArcGIS vous trouverez très facilement les deux scripts Python qui permettent de compresser et de décompresser. Vous récupérerez donc ces deux scripts pour les placer, par exemple, dans le répertoire C:\Program Files\ArcGIS\ArcToolbox\Scripts de votre poste.

Pour utiliser le script Zip.py dans votre modèle, vous devrez tout d'abord l'ajouter dans votre ToolBox en tant qu'outil.

Vous apporterez une attention particulière aux types des paramètres attendus par l'outil:
- le répertoire à zipper qui sera de type Workspace (Espace de travail en VF)
- le fichier zip en sortie qui sera de type File (Fichier en VF)


Votre outil est alors prêt à fonctionner vous pouvez désormais l'utiliser comme n'importe quel autre outil de la ToolBox



Evolution de notre modèle

Nous allons donc faire évoluer notre modèle pour compresser les fichiers de formes résultants du découpage en un seul fichier Zip.

Vous allez tout d'abord ajouter l'outil Zip dans votre modèle puis associer le paramètre en entrée au paramètre "Répertoire résultats" qui le répertoire que l'on souhaite compresser. Vous indiquerez également le nom du fichier Zip à créer en sortie. Pour que notre modèle reste générique, pensez à utiliser la variable %ScratchWorkspace% dans tous les chemins d'accès des résultats produits par le modèle.


Il faut ensuite s'assurer que cet outil ne s'exécute qu'après la création des couches découpées. Pour cela, il suffit d'utiliser une pré-condition sur l'outil Zip à partir du paramètre "Résultats".

Notre modèle ressemble désormais à ceci :



A bientôt pour la suite …

Une API JavaScript/REST pour ArcGIS Server 9.3

La conférence mondiale des utilisateurs ESRI de San Diego coïncidera avec la sortie de la version 9.3 d'ArcGIS (en anglais), une raison de plus pour vous encourager particulièrement cette année à nous y rejoindre. En attendant, parlons un peu d'avenir en levant un petit bout de voile sur une des évolutions importantes d'ArcGIS en version 9.3.

En version 9.2, l'API SOAP/XML d'ArcGIS Server permet d'accéder de n'importe quel environnement de développement aux fonctionnalités de cartographie, de géocodage, de géotraitement ou d'extraction/insertion en base de données via le Web. En version 9.3, ESRI ajoutera une nouvelle API REST (coté serveur) et JavaScript (coté client) pour faciliter le développement d'applications Web consommant des services ArcGIS Server.

A l'occasion du Super Tuesday, nos collègues américains de l'équipe de développement ArcGIS Server viennent de publier un exemple d'application utilisant cette API Javascript et REST. L'application est un exemple de mashup entre plusieurs services de cartes ArcGIS Server (résultats des élections et fonds ArcGIS Online) mais également avec l'utilisation de l'API Google Chart.

Une API REST pour quoi faire ?

Avoir une API REST (REpresentational State Transfer) sur les services ArcGIS Server c'est permettre l'accès, via de simples requêtes http, aux fonctionnalités (capibilities) de ces services. Quelle que soit la nature du service ArcGIS Server, un développeur pourra y accéder avec des langages de scripting tels que Python, PHP, Ruby ou encore JavaScript. En utilisant l'API REST, le développeur pourra envoyer une URL avec quelques paramètres à son serveur SIG et récupérer le résultat sous la forme d'un objet simple (utilisation du JSON pour la sérialisation/désérialisation).

Pour mieux comprendre le fonctionnement de l'API REST, ArcGIS Server disposera d'un explorateur de services qui exposera les différentes API. Vous pouvez voir un exemple ici.

Pour les plus anglophones d'entre vous, vous pouvez toujours écouter le podcast suivant : ArcGIS Server REST services

Une API JavaScript pour quoi faire ?

Complément quasi indispensable de l'API REST, ESRI fournira avec ArcGIS Server 9.3 une API JavaScript très simple à utiliser pour permettre à des développeurs non chevronnés de créer des sites web intégrant des fonctions SIG en écrivant quelques lignes de JavaScript. Basé sur une philosophie très proche des API JavaScript de Google Maps ou Virtual Earth, l'API JavaScript d'ArcGIS Server 9.3 sera très richement documentée pour permettre à chacun de tirer pleinement profit de toutes les fonctionnalités des services Web de votre serveur SIG (tâches de géotraitement, géocodage, manipulation de géométrie, cartographie, consultation de données, insertion/extraction de données,…).

Un dernier point très intéressant, l'API JavaScript pourra être utilisée également conjointement aux API Google Maps et Microsoft Virtual Earth pour réaliser des applications de mashups combinant à la fois des services de carte et des services de fonctionnalités de ces fournisseurs grand public avec ceux d'ArcGIS Server.

Toujours pour les plus anglophones d'entre vous, vous pouvez toujours écouter le podcast suivant : ArcGIS JavaScript APIs

Ceci n'est bien entendu qu'un apperçu, nous aurons l'occasion dans les prochains mois de revenir sur cette évolution importante d'ArcGIS Server.

Géotraitements - N°6 : Définir l'ordre d'exécution des outils

Nous continuons notre série d'article sur les géotraitements. Aujourd'hui, nous allons faire évoluer notre modèle afin de créer un répertoire pour stocker les résultats du découpage de nos couches. Par la suite (dans notre prochain article) ce répertoire sera archivé sous la forme d'un fichier ZIP. Ce fichier ZIP constituera le résultat final de notre modèle de géotraitement. Pour que notre modèle fonctionne correctement, nous devons nous assurer que ce répertoire est bien créé préalablement à l'exécution des fonctions de découpage des couches.

Définir l'ordre d'exécution des éléments d'un modèle

Pour définir l'ordre d'exécution des différents outils qui constituent un modèle, vous devez utiliser une variable de pré-condition. Une variable de pré-condition permet de spécifier qu'un outil ne sera exécuté que si le résultat d'un autre outil a préalablement été produit.

Dans cet exemple, l'outil 3 est exécuté avant l'outil 2 lui même exécuté avant l'outil 1.

Pour spécifier une pré-condition, vous devez modifier les propriétés de l'outil. Vous cocherez, dans l'onglet Précondition, les variables qui devront avoir été préalablement produites avant que l'outil ne puisse s'exécuter. Dans l'exemple ci-dessous on indique que l'outil 2 sera exécuter une fois que la variable Résultats 3 sera produite.

Evolution de notre modèle

Nous allons donc faire évoluer notre modèle pour le préparer à un futur déploiement sous la forme d'un service de géotraitement. L'objectif est que les couches découpées soient regroupées dans un même répertoire en sortie. Notre modèle va donc devoir créer le répertoire avant d'exécuter le reste du modèle.

Pour cela, il suffit d'ajouter la commande de création de répertoire. Vous remarquerez à nouveau l'utilisation de la variable %ScratchWorkspace% pour indiquer que notre répertoire sera créé dans l'espace temporaire de travail.

Il s'agit ensuite d'associer une pré-condition à l'outil sur la variable "Couche de découpage".

Après avoir cliqué sur le bouton OK, vous constatez qu'une ligne pointillée signale la pré-condition d'exécution.

Notre modèle ressemble désormais à ceci :

A bientôt pour la suite …

Déployer dynamiquement des extensions de classe

Je dois le reconnaitre, depuis la création d'arcOrama, on n'a pas beaucoup abordé les problématiques de développement alors qu'il y a pourtant beaucoup de sujets à traiter. Une publication récente sur ArcScripts m'a soufflé l'idée de revenir sur la notion d'extension de classe (ClassExtension en langage développeur) et sur les différentes options de déploiement envisageables.

Notion d'extension de classe

Il y a 10 ans, ESRI met au point la Géodatabase, point central de la gamme ArcGIS. Au delà du stockage de données spatiales dans des SGBD, la Géodatabase introduit une idée assez géniale qui consiste à pouvoir étendre les comportements des entités (features). C'est ce que permet de faire une ClassExtension en fournissant aux développeurs la possibilité de modifier le comportement des éléments d'une classe d'entités (points, lignes, polygones) ou d'une table. Les extensions de classes sont le moyen le plus simple et plus intégré à ArcGIS pour gérer des comportements spécifiques sur des objets métiers, notamment pour :

• appliquer des règles de validation complexes
  (implémentation de IObjectClassValidation)


• d'associer des actions spécifiques aux événements déclenchés lors de la mise à jour
  (implémentation de IObjectClassEvents et IRelatedObjectClassEvents)


• personnalisation de la boîte de dialogue des attributs
  (implémentation de IObjectInspector)


• personnalisation du rendu des entités d'une classe
  (implémentation de IFeatureClassDraw)


• automatisation de la création et de la préconfiguration de nouvelles tables ou de classes d'entités
  (implémentation de IObjectClassDescription et IFeatureClassDescription)

Déploiement classique d'une extension de classe

Concrètement, une extension de classe est composant COM (sous la forme d'une dll) développé avec VB 6, Visual C++, VB .Net ou C#. Cette dll est associée à une classe d'entités ou à une table d'une Géodatabase. Le lien entre la dll et la classe d'entités repose sur le CLSID de la dll qui stocké dans la Géodatabase. Le déploiement de la ClassExtension se fait donc en distribuant la dll sur chaque poste client (ArcGIS Desktop, ArcGIS Engine ou ArcGIS Server).

L'inconvénient de cette méthode de déploiement réside dans le fait de devoir distribuer la dll sur chaque poste. Ceci peut s'avérer problématique si le déploiement doit se faire individuellement (c'est à dire non pas packagé dans une application) ou si de fréquentes mises à jours sont effectuées sur la dll.


Déploiement dynamique d'une extension de classe

L'arrivée du framework .Net 2.0 permet d'envisager une deuxième solution. En effet, en utilisant les fonctionnalités de compilation de code source à la volée de la librairie CodeDom, il devient possible de stocker le code source de l'extension de classe en base de données et de le compiler lors de l'utilisation de la classe d'entités. Il n'y a alors aucune dll à déployer car le code source est stocké de manière centralisée dans la Géodatabase.

Kirk Kuykendall a réalisé un prototype en .Net qui fait une belle démonstration de ce mécanisme en proposant sur le site ArcScripts un outil générique permettant de gérer dynamiquement une liste de plusieurs extensions classes. Cette liste d'extensions de classes est maintenue coté client par une extension de l'éditeur (EditorExtension). L'outil est fourni avec un exemple d'extension de classe, une Géodatabase et le code source de l'extension d'éditeur (VS 2005).

J'ai testé l'outil sur plusieurs jeux de données et cela fonctionne bien. Si vous devez développer une application utilisant plusieurs extensions de classes, je vous conseille vivement d'étudier cette solution.

Analyser vos caches ArcGIS Server

De plus en plus d'applications ou de services web ArcGIS Server utilisent des caches. Nous avons déjà évoqué à plusieurs reprises cette notion de cache dans ArcGIS Server 9.2. Pour mémoire, les caches sont des cartes pré-calculées et découpées en tuiles pour certaines échelles prédéfinis. Cette technique permet de mettre en ligne des services web cartographiques très performants comme ceux de Google Maps, Yahoo Maps ou encore Virtual Earth.

Une fois le cache mis en place, il deviendra parfois intéressant de pouvoir analyser le contenu de ce cache ou encore de suivre la fréquence d'accès des différentes tuiles.

Exemple de carte de fréquentation d'un cache ArcGIS Server sur la France

Pour réaliser ce type d'opération, je viens de mettre en ligne sur le site du support d'ESRI France un outil permettant d'analyser ses caches ArcGIS Server. A l'aide de cet outil complémentaire vous pourrez, par exemple, rechercher les éventuelles zones où les tuiles n'ont pas encore été générées ou encore consulter la taille moyenne des tuiles sur certaines zones stratégiques de votre application. Vous pourrez également connaître les niveaux d'échelle les plus consultés ou encore les zones géographiques les plus visualisées par les utilisateurs de votre application.