Cours Arcgis Developpement

Cours

Introduction à ArcGIS pour le développeur

Alexandre Pauthonnier

Juillet 2010

TABLES DES MATIERES Introduction ................................. 4

I. Présentation brève d’ArcGIS ............... 5 I.1. Les applications bureautique.................. ..............................5 I.2. Les applications serveur...................... ..............................6

I.2.1. ArcIMS...................................... ............................7 I.2.2. ArcGIS Server ............................... ............................7

I.3. Les applications mobiles...................... .............................15 I.4. Les services web hébergés..................... .............................15

II. Présentation des différents types de développement. .............................. 18

II.1. Produits bureautiques........................ .............................18 II.1.1. Personnalisation et extension.............. ...........................18

II.1.1.1. Personnalisation avec VBA ................ .........................18 II.1.1.2. Extension avec VB ou .NET ................ .........................21 II.1.1.3. Développement d’outils de géotraitement .. .........................22

II.1.2. Création d’applications.................... ...........................26 II.2. ArcGIS Serveur ..................................... ...................27

II.2.1. Utilisation de l’assistant ......................... .................27 II.2.2. APIs Javascript ............................ ...........................29 II.2.3. APIs Flex et SilverLight ................... ...........................33

II.2.3.1. API Flex ................................. .........................33 II.2.3.2. API SilverLight .......................... .........................35

II.2.4. le Web ADF (Application Development Framewo rk) ........................35 II.2.5. Résumé..................................... ...........................37

III. Le développement bureautique avec l’API ArcObjects .................................. 39

III.1. Les ArcObjects.............................. .............................39 III.2. La norme COM................................ .............................40 III.3. Les interfaces.............................. .............................41

III.3.1. Définition................................ ...........................41 III.3.2. Un monde orienté-objet .................... ...........................42 III.3.3. L’interface IUnknown et les autres........ ...........................43

III.4. Développer avec les ArcObjects.............. .............................43 III.4.1. Les diagrammes de classe.................. ...........................43 III.4.2. Considérations sur l’utilisation des ArcOb jects en environnement VB. .44 III.4.3. Pratique des concepts de classe et d’inter face.......................47

ANNEXES ..................................... 50 Annexe 1 : personnalisation Arcgis bureautique en V BA...........................50 Annexe 2 : extension ArcGIS bureautique avec Micros oft Visual Basic 6...........53 Annexe 3 : extension ArcGIS bureautique avec Micros oft .Net.....................58 Annexe 4 : retour sur la programmation d’évènements avec l’API ArcObjects.......66 Annexe 5 : Création d’une application web avec visu al studio 2005 à partir du template d’application livré avec ArcGIS Server.... .............................70 Annexe 6 : démarrer avec l’API Javascript.......... .............................74

Partie 1 : inclure une carte dans une page web..... ...........................74 Code : ............................................. .........................74 Commentaires : ..................................... .........................74

Partie 2 : programmer un évènement ................. ...........................75 Commentaires : ..................................... .........................76

Partie 3 : ajouter des données servies dynamiquemen t en WMS...................76 Code : ............................................. .........................76 Commentaires : ..................................... .........................78

Partie 4 : ajouter des données en cache sur un serv eur (ex: les données OpenStreetMap). Utiliser les widgets du Dojo. ...... ...........................78

Code : ............................................. .........................78 Commentaires : ..................................... .........................81

Juillet 2010 – v3.1

Alexandre Pauthonnier 3/82

Partie 5 : faire afficher les résultats d’une requê te vers un serveur ArcGIS Serveur sur un fond Google Maps.................... ...........................82

Code : ............................................. .........................82 Commentaires : ..................................... .........................83



Introduction L’aptitude à programmer ou développer en surcouche d’un noyau SIG est un plus indéniable : bien souvent, c’est la source d’un gai n de productivité important. En effet, un utilisateur de SIG est amené dans l’exerc ice de son métier à reproduire un grand nombre de fois des opérations ou des trait ements semblables. S’il dispose d’outils qui automatisent tout ou partie de ces tra itements, c’est un gain de temps considérable. Par ailleurs, l’évolution récente du monde de l’inf ormation géographique vers la mise en ligne de données et de services (sur le web ou bien au sein de réseaux d’entreprises) n’a fait qu’augmenter les besoins en développement dans ce secteur d’activités. La tendance est aujourd’hui à la créat ion d’interfaces clientes, entièrement personnalisées, répondant au plus près aux besoins de l’utilisateur. Ces interfaces consomment des ressources (services web), locales ou distantes, exposées à travers des API. La mise en place de tou t cela est du ressort du développeur. Face à ces enjeux, les produits ArcGIS apportent de s solutions complètes et de grande qualité. On observe tout d’abord que la gamme couvre tous le s types de besoin. Pour ce faire, Esri utilise des outils modernes adaptés aux standards actuels des technologies de l’information. Ces standards étant en perpétuelle évolution, ArcGIS évolue lui aussi au même rythme ; ainsi ArcGIS a pr is le virage du web il y a quelques années, puis celui du web 2.0 avec la géné ralisation de technologies telles Ajax ou l’utilisation de protocoles interopé rables tels SOAP ou Rest. On observe ensuite que tous les produits sont « ouv erts » : le développeur peut donc personnaliser, étendre, voire remanier profond ément le SIG tel qu’Esri l’a conçu. Le tout en utilisant les langages (VB, VB.NE T, Java, Python) et les environnements de développement (Microsoft Visual S tudio, environnements Java) les plus populaires. D’un point de vue architecture logicielle, ArcGIS a été conçu comme un ensemble de composants COM, une norme qui reprend les grands pr incipes de l’orienté-objet et qui assure une réutilisabilité maximale de ces comp osants. Ces derniers sont accessibles aux développeurs à travers une API : le s ArcObjects. Cette API s’adresse essentiellement aux développeurs de fonct ions métiers. Pour mettre en place des applications aux fonctionnalités plus gén ériques, ESRI propose d’autres APIS, notamment pour la création d’applications de webmapping. La force d’ArcGIS tient aussi en grande partie à sa large communauté d’utilisateurs. Cette communauté représente une aid e précieuse pour le développeur novice ou chevronné, et ce notamment à travers les nombreux codes source téléchargeables.



I. Présentation brève d’ArcGIS ArcGIS est une suite intégrée d’applications logici elles SIG. Les différents produits permettent d’exploiter les données géograp hiques dans un contexte bureautique, à travers un réseau intranet ou intern et ou encore sur le terrain. L’ensemble forme un système complet de création, d’ administration, d’exploitation et de mise à disposition de contenu géographique (d onnées ou service).

On distingue : • Les applications bureautiques • Les applications serveur • Les applications mobiles • Les services web hébergés

I.1. Les applications bureautique Il s’agit d’abord d’ArcGIS bureautique (ou ArcGIS D esktop) : une suite composée d’ArcMap, ArcCatalog, ArcGlobe et ArcScene. Ces app lications permettent de

• Gérer les données géographiques, i.e. créer et admi nistrer des bases de données (ou bien des sources de type fichier) conte nant de l’information géographique, créer et mettre à jour la sémantique, la géométrie, la topologie et les métadonnées

• Intégrer des données existantes archivées dans dive rs formats



• Diffuser les données dans divers formats • Créer des cartes ou des globes • Prétraiter et analyser les données • Créer des modèles de géotraitement

Il existe 3 niveaux de licence qui donnent accès à plus ou moins d’outils : ArcView, ArcEditor et ArcInfo. Il s’agit d’un produ it clé en main, qui peut toutefois être complètement adapté aux besoins de l ’utilisateur. On trouve également dans cette famille d’applicatio ns les produits développés avec ArcGIS Engine. ArcGIS Engine, c’est un run-time et un kit de développement destin és aux développeurs et conçus pour la création d'appli cations bureautique personnalisées intégrant des fonctions SIG (voir un exemple d’applications ). Les produits développés avec Engine sont des progiciels métiers qui sont destinés à un public très ciblé. Enfin on trouve également ArcGIS Explorer, une appl ication que l’on peut télécharger gratuitement qui permet de visualiser l es données géographiques mais aussi, dans une certaine mesure, de les exploiter. On peut notamment créer des cartes en mêlant des sources de données diverses (l ocales, services web), utiliser quelques outils simples d’analyse spatiale (recherc he sur critère de proximité). A noter que toutes les applications bureautique ont la capacité de jouer le rôle de clients web ou intranet et ainsi d’exploiter les services web diffusés par des serveurs géographiques : ArcGIS Server, ArcIMS, Arc GIS online pour les serveurs Esri, serveurs WMS et WFS pour les serveurs OGC. De nombreux tutoriels, sous forme de documents pdf et de vidéo sont accessibles en ligne à l’adresse suivante :

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm ?TopicName=Tutorials

Ces tutoriels couvrent l’ensemble des fonctionnalit és offertes par la suite bureautique.

I.2. Les applications serveur La technologie SIG serveur répond à d’autres problé matiques que la technologie bureautique :

• partager le SIG • intégrer le SIG dans le système d’information de l’ entreprise.

Il s’agit de mettre à disposition de plusieurs memb res d’une même organisation, ou de plusieurs organisations, voire à un public aussi large que possible des ressources de nature géographique. Ces services peu vent être des cartes, de la donnée brute, des traitements sur les données. Cette technologie s’appuie sur le modèle de communi cation client-serveur utilisant les protocoles HTTP et TCP/IP et est bâtie en cohér ence avec les normes et standard développés par le W3C (World Wide Web consortium) e t l’OGC (Open GIS Consortium). Elle est ainsi conçue pour s’intégrer au SI de l’en treprise : elle est notamment interopérable avec les toutes les applications web de l’entreprise qui obéissent aux mêmes standards (outils CRM de gestion de la re lation client, outils ERP de planification des ressources, …) Cette technologie serveur est complémentaire de la technologie bureautique , en ce sens qu’elle permet de diffuser ce qui a été créé avec les outils bureautique : le s cartes, les globes, les modèles d’analyse et de géo traitement. Les produits serveur permettent enfin de déployer d es outils qui répondent précisément au besoin et au profil de leurs utilisa teurs. L’accès aux services hébergés sur le serveur (données, cartes, traitemen ts) se fait le plus souvent à travers des clients web légers dont l’interface épu rée ne propose que les seules fonctionnalités utiles.



Il est également possible d’accéder aux services à travers d’autres clients (dits « lourds »)

• des clients bureautique (ceux décrits au paragraphe précédent) • des clients mobiles

ArcGIS comprend 2 produits serveurs : ArcGIS Serveu r et ArcIMS qui ne s’inscrivent pas dans la même dynamique. ArcGIS Serveur est la t echnologie innovante tandis qu’ArcIMS est une technologie qui n’évolue plus et qui n’est maintenue que par soucis d’assurer la continuité du service vis-à-vis des clients. Celui qui développe aujourd’hui un nouveau site web avec une dimension cartographique avec un produit Esri doit utiliser ArcGIS Server.

I.2.1. ArcIMS Quelques mots de présentation malgré tout. C’est un serveur cartographique permettant de publi er de la cartographie dynamique (webmapping) ainsi que des catalogues de métadonnée s. L’outil est fourni avec un assistant de création de site web. Toutefois la mis e au point d’un site finalisé implique souvent la programmation de fonctionnalité s métier côté serveur et presque toujours un minimum de personnalisation de l’interf ace côté client. Côté client, on programme en HTML, CSS, Javascript; côté serveur, le site peut être développé en ASP.NET (Active Server Page, technolog ie Microsoft) ou en JSP (Java Server Page, technologie Java). La communication client-serveur repose sur un flux XML (ArcXML). On peut accéder aux services cartographiques ArcIMS avec un simple navigateur, mais aussi avec les produits bureautiques ou serveur.

I.2.2. ArcGIS Server C’est un serveur SIG à part entière, c'est-à-dire u n ensemble d’outils et de technologies web permettant le partage de ressource s SIG sur un réseau. L’idée est de donner accès à travers un navigateur aux mêmes f onctionnalités que celles offertes par les SIG bureautiques. Un serveur SIG n ’est donc pas un simple visualisateur de cartes (et encore moins un simple serveur web) ; c’est un outil permettant d’interagir pleinement avec l’informatio n géographique et notamment à des fins d’analyse et d’aide à la décision. Un usag e grand public d’un tel serveur serait par exemple de permettre l’identification du bureau de poste le plus proche d’un lieu donné puis le calcul et l’affichage de l’ itinéraire pour s’y rendre.



Comme toutes les solutions webs, une solution ArcGI S Server s’inscrit dans une architecture client-serveur reposant sur le protoco le de communication HTTP. La partie serveur est constituée de programmes et de d onnées hébergées physiquement sur une ou plusieurs machines, dites serveur . Le serveur a ainsi pour tâche d’héberger les ressources SIG mais aussi de les re ndre accessibles. C’est la partie client qui accède aux ressources. Une partie des traitements peut éventuellement être déléguée par le serveur au clie nt. Toutefois, selon la philosophie d’une telle architecture, c’est le serv eur qui exécute la plupart des traitements, le client se contentant d’afficher les résultats.

Le premier rôle d’ArcGIS Server est d’héberger les ressources SIG , lesquelles sont de différentes natures :

• des données brutes (fichiers ou tables de bases de données) • des données cartographiées (documents cartographiqu es, globes 3D) • des géo-traitements ou fonctions permettant d’inter agir et donc d’exploiter

les données (la boîte à outils du SIG) • des géo-traitements personnalisés, i.e. des chaînes de traitements SIG

capable de produire de nouvelles informations à par tir de données en entrée. N.B : les ressources peuvent être réparties en deux catégories : celles qui sont fournies avec ArcGIS Server (les outils) et celles que l’on crée (les cartes, les bases de données, les traitements métier). Pour créer une ressource, on utilise la suite ArcGIS bureautique (ArcCatalog, ArcMap, ArcGl obe, Modelbuilder et Python pour les processus de géo-traitement). Lorsque les données spatiales sont archivées dans u ne base de données multi-utilisateurs, il est nécessaire d’installer ArcSDE pour faire le lien entre ArcGIS Serveur et le SGBD (Oracle, SQL Server, PostgreSQL) . Si le besoin ne justifie pas le recours à un SGBD d’entreprise, il est tout à fa it possible d’archiver les données géographiques dans des formats fichiers ou géodatabase personnelle. Afin de rendre les ressources partageables, le serv eur expose les ressources sous forme de services . Un service peut être vu comme la représentation n ormalisée d’une ressource, rendue de ce fait consommable par des cl ients sur un réseau ; le partage peut être limité à une entreprise (intranet, réseau local), étendu à un ensemble de partenaires (extranet, accès sécurisé par identifia nt et mot de passe) voire étendu à tout l’internet. C’est le deuxième rôle joué par le serveur SIG : pu blier les ressources. La logique de service permet de passer d’une architecture client-serveur à une architecture distribuée ( SOA, architecture orientée service ). Dans une telle architecture, les données et les traitements requis par un client peuvent être stockés physiquement sur des machines différentes p ourvu que celles-ci soient connectées par le réseau. La logique de service implique également la normalisation des accès à la fonctionnalité : l’obj ectif est de permettre à différents types de clients, lourds, riches, légers , mobiles de consommer le service ; cela passe par l’utilisation de protocole s de communication standardisés et par la normalisation des interfaces qui exposent les ressources. ArcGIS Server permet essentiellement de publier des services de type cartes 2D (map services), cartes 3D (globe services), image, géo-t raitement (geoprocessing service), géocodage, geodata et géométrie. Pour publier un map service , il faut déjà créer un document ArcMap (mxd). Il f aut ensuite le stocker dans un répertoire accessible pa r ArcGIS Server et s’assurer que les données géographiques qu’il contient sont égale ment accessibles par ArcGIS Server. Pour publier un geoprocessing service , il y a 2 façons de procéder : soit on crée une toolbox contenant un ou plusieurs outils (des modèles créé s avec ModelBuilder ou bien des scripts Python) et on la publie directe ment. Soit on ajoute la toolbox à un document ArcMap sous forme d’une tool layer et on publie le document. Dans les deux cas, le serveur réalise un traitement sur des données géographiques et renvoie un lot ou plusieurs lots de données traitées. Ce qu i diffère c’est la façon dont on accède aux données : dans le premier cas, les donné es doivent être chargées en mémoire, tandis que dans le second elles le sont dé jà si elles figurent en tant que couches dans le document. Si le géotraitement est c oûteux en temps d’exécution, on



privilégiera donc la deuxième solution. Il est poss ible aussi d’associer un geoprocessing service à un result map service. Par défaut, les données renvoyées par le service de géotraitement sont non symbolisée s, elles sont livrées en vecteur au client: charge à lui de les symboliser. L’association à un result map service permet au serveur de cartographier le résultat du géotraitement : le client n’a plus qu’à afficher l’image fournie. Pour publier un geocode service , il faut créer au préalable un locator ou localisateur d’adresses avec ArcCatalog. Un tel objet permet de décrire un e méthode de géocodage (ex : géocodage à l’adresse postale) p ar rapport à un référentiel (ex : la BD Adresse® de l’IGN). Les geodata service permettent d’interagir avec les données d’une geod atabase par le biais d’ArcGIS Server. Ils permettent l’exploita tion (requêtes) et l’administration (extraction, réplication, …) de do nnées à distance par le réseau. Là encore il y a deux façons de procéder : soit on publie directement une geodatabase, soit on ajoute à un document ArcMap le s tables que l’on souhaite publier et on publie le document. Les geometry service sont pour certains géotraitements simples une alte rnative aux geoprocessing service . Ils permettent de réaliser des calculs relatifs à la géométrie d’une ou plusieurs entités : buffer, simp lification de polyligne, changement de système de coordonnées, … Il ne peut y avoir qu’un seul geometry service par serveur. Il doit nécessairement s’appeler geometry . Pour une présentation plus complète sur les services , consulter en ligne le centre de ressources d’ArcGIS sur ce sujet. On administre les services (création, arrêt, démarr age, paramétrage) à l’aide d’ArcCatalog , d’ArcMap, ou encore d’une application web, livrée avec ArcGIS Server, le Manager . Ainsi qu’on l’a évoqué précédemment, la logique de service va également de pair avec celle d’interopérabilité. Il est tout à fait p ossible de concevoir une architecture dans laquelle les clients qui consomme nt les services d’ArcGIS Server sont des clients bureautiques ESRI (ArcMap, ArcGlob e …), ou encore le client lourd librement téléchargeable ArcGIS Explorer . En effet, ces clients ESRI ont la capacité à afficher et manipuler à l’identique des données géographiques qu’elles soient stockées en local ou bien servies par un map service. Idem pour les géotraitements qu’ils soient locaux ou sous forme d e geoprocessing services . Dans ce cas précis, la communication se fait selon un pr otocole binaire propriétaire. Toutefois, rappelons que les ambitions d’un SIG ser veur vont bien au-delà de cette utilisation propriétaire. Il s’agit de donner d’acc éder au SIG à travers des clients moins coûteux, plus nombreux et plus ciblés fonctionnellement : les principaux consommateurs de services ArcGIS Server sont donc les navigateurs webs, et plus précisément des applications personnalisées développées dans différents langages. L’autre objectif est de décloisonner le S IG, et notamment de donner l’accès à la donnée à quiconque peut en avoir l’usa ge quel que soit les outils qu’il possède. ArcGIS Server a été conçu pour répondre à ces besoi ns. Par défaut les services créés sont accessibles selon deux protocoles : le p rotocole binaire évoqué plus haut et SOAP. SOAP est un protocole standardisé dan s lequel la communication est assurée par des requêtes HTTP et des flux XML. Tous les langages serveur (asp, php, jsp) utilisés pour développer une application web o ffrent des objets capables de générer et parser des messages SOAP/XML. Il est don c possible de développer côté serveur une application consommant des services Arc GIS Server. Il est également possible de publier les services en REST. REST est également un protocole standardisé d’accès à des services webs : en REST, chaque ressource est accessible simplement par son URL. Les ressources sont rangées dans une arborescence de dossiers. L’accès en REST à un service se fait donc à l’aide de requête HTTP : c’est ainsi par exemple que fonctionne l’API Google Maps qui propose des services de géocodage, de calcul d’itinéraires, de localisat ion 3D. Les possibilités de développements d’application sont donc encore plus grandes en REST qu’en SOAP : en effet, pour consommer il suffit d’être capable d’en voyer une requête HTTP ; c’est possible avec un client Javascript AJAX. On peut do nc développer côté client.



N.B : si vous souhaitez approfondir ces notions, vo us pouvez consulter le site viamichelin ( http://doc.apir.viamichelin.fr/web/api-rest ) qui décrit de manière très détaillée ses services REST et SOAP. L’interopérabilité se manifeste également par la pu blication des services selon les normes OGC. Ces normes (WMS, WFS, WCS) permettent r espectivement de publier les couches d’une carte sous forme d’une image, les don nées spatiales sous forme de vecteur ou de raster et ce dans une sorte d’esperan to, reconnu directement par tous les SIG, propriétaires ou Open Source. Contrairemen t à ce qui a été vu précédemment, il n’est pas nécessaire de développer une application pour consommer le service, il suffit d’utiliser son SIG habituel ( MapInfo, QGIS, GeoConcept, ArcGIS, Geomedia, …) Cette publication sous forme de service OGC n’est p as automatique : il faut l’indiquer explicitement au moment de la publicatio n. En résumé, les services publiés par ArcGIS Server s ont consommables sur le web (ce sont donc des Web services ) par des clients de tout type . A chaque service est associée une url selon le modè le suivant http://<nom du serveur>/<nom de l’instance arcgis s erver>/services/<nom du service>/<type de service> et plusieurs urls complémentaires pour chaque type d’interopérabilité http://<nom du serveur>/<nom de l’instance arcgis s erver>/services/<nom du service>/<type de service>/<capability> où capability désigne le type d’interopérabilité soit pour un service de carte nommé test_arcpad, contenant des couches de type vecteur et raster, et hébergé sur le serveur monser veur les urls suivantes • interopérabilité ArcGIS :

http://monserveur/arcgis/services/test_arcpad/MapS erver • interopérabilité WMS :

http://monserveur/arcgis/services/test_arcpad/MapS erver/WMSServer • interopérabilité KML :

http://monserveur/arcgis/services/test_arcpad/MapS erver/KmlServer • interopérabilité WFS :

http://monserveur/arcgis/services/test_arcpad/MapS erver/WFSServer • interopérabilité WCS :

http://monserveur /arcgis/services/test_arcpad/Map Server/WCSServer

Ces url ne peuvent pas être requêtées directement par un n avigateur. Il suffit néanmoins d’ajouter /?wsdl à chacune des url indiqu ées ci-dessus, pour obtenir en retour la description des services sous forme de fi chiers xml. Ce sont des requêtes SOAP. Pour accéder en REST aux services, on utilise le se rvice de catalogage REST du serveur ArcGIS lui-même accessible par l’url http://<nom du serveur>/ArcGIS/rest/services. L’exemple ci-dessous nous montre les services hébergés par les serveurs ArcGISOnline ( http://sampleserver1.arcgisonline.com/ArcGIS/rest/s ervices ) :



Les services sont ici organisés dans une arborescen ce de dossiers. Un système d’hyperliens permet d’accéder à la description de c haque service hébergé, ainsi qu’à chacune des opérations exposées. N.B : il est nécessaire d’exécuter la web application post-installation pour activer l’API Rest. Afin de contrôler l’exécution c orrecte de cette post-installation, ouvrir le fichier rest.config stocké dans le répertoire ArcGIS du serveur web IIS. L’interopérabilité est un des nombreux paramètres à considérer lorsqu’on publie une ressource. Il convient également de choisir une str atégie concernant le partage entre les clients de la CPU de la machine serveur : limiter d’une part l’accès à un nombre restreint d’utilisateurs ; ouvrir ensuite l’ accès en mode poolé ou non poolé . Dans le premier cas, tous les clients d’un même s ervice interagissent avec le même processus côté serveur (un seul SOC, server object container, pour tous les clients d’un même service, voir figure ci-dessous) ; dans le deuxième cas, chaque client se voit attribuer un processus différent (au tant de SOCs que de connexions ouvertes). La deuxième solution garantit certes des temps de réponse meilleurs pour le client mais elle nécessite beaucoup de RAM sur l e serveur : un service de carte ouvert pour 5 connexions en mode non poolé consomme grosso modo 5 fois l’espace nécessaire à la mise en mémoire du document ArcMap.



Il convient aussi de réfléchir à l’opportunité de p ré-calculer un cache pour les données cartographiques de type image. Selon l’éten due et la résolution des données à publier, un cache, i.e. le calcul et le stockage sur le serveur de dalles associées à différentes échelles pré-définies peut améliorer considérablement les temps d’affichage sur le poste client. Par défaut, la création d’un service de carte ou d’images n’entraîne pas la création automa tique de cache. En l’absence de cache, l’accès aux données est réellement dynamique et le client peut donc demander à afficher les données à n’importe qu’elle échelle ; le serveur crée alors l’image à la demande et l’adresse au client ; c’est évidemm ent plus long. La création d’un cache n’est pas prise en charge par les interfaces d’administration (ArcCatalog ou Manager) ; il faut utiliser des outils ArcToolBox. Utiliser un cache peut être vu comme une contrainte (affichage à des échelles préd éfinies) mais cela garantit une réelle fluidité d’affichage (Google Maps et Google Earth fonctionnent selon ce principe). Le troisième et dernier rôle d’ArcGIS Server consis te à permettre la création d’applications webs permettant d’interagir avec les services. Les services sont en effet destinés à être consommé s par une application cliente. Il peut s’agir de clients sur étagère :

• suite ArcGIS bureautique (arcmap, arccatalog) • Arcgis Explorer • client nomade ArcPad • client WMS (QGIS) • client KML (Google Earth)

Ou bien de clients personalises

• Client développé avec l’API Javascript AJAX OpenLay ers • Client développé avec l’API Javascript AJAX Google Maps • Client mobile IPhone ou Android



Ainsi qu’on l’a déjà dit, l’utilisation d’ArcGIS Se rver passe souvent par le développement d’un client personnalisé. Le Manager propose une interface pour créer très simplement u n client léger consommant des ressources hébergées en local ou sur d’autres serveurs ArcGIS. L’application ainsi créée utilise côté serveur l’API Web ADF (.Net ou Java selon l’installation du serveur), qui est une simplification de l’API ArcObjects : son IHM est à base de web controls, exécutant des requê tes en AJAX vers le serveur. C’est un client léger, car l’essentiel des traiteme nts SIG sont exécutés côté serveur (en .Net ou Java). Cette application ne répond pas à tous les besoins dans la mesure où elle ne dispose que des fonctionnalités prévues en standard (navigation, interrogation, édition). Si l’on souhaite disposer de fonctionnali tés métier, il convient de les développer et des intégrer à l’IHM. Il y a alors pl usieurs façons de procéder. On peut modifier le template d’application en insérant ses développements. On peut aussi définir une IHM totalement différente. Pour des développements légers, on préférera dévelo pper côté client à l’aide des API Javascript, Flex ou Silverlight. ArcGIS Server est commercialisé en 3 niveaux de lic ence : Basique, Standard et Advanced. Le tableau suivant récapitule les différe ntes fonctionnalités associées à chacun des niveaux :

Advanced Standard Basique

Gestion des données

Fournit des services de géodonnées permettant aux administrateurs de publier des données géographiques pour extraction ou réplication. Stocke les données géospatiales dans un SGBDR, par exemple IBM DB2, IBM Informix, Oracle, Microsoft Access, Microsoft SQL Server ou PostgreSQL. X X X

Services Web SIG

Prend en charge les services Web, dont les services de cartes, globes, d'imagerie, WMS, WFS-T, WCS, KML, géocodage et géotraitement. Les accès REST et SOAP, ainsi que les services de géodonnées, sont inclus à tous les niveaux. X X

Cartographie

Comprend des outils de création d'applications web cartographiques riches fonctionnant dans des navigateurs X X

Analyse spatiale

Prend en charge les analyses et les géotraitements serveur, avec notamment des données vectorielles , des rasters, de la 3D , de l'analyse de réseau, ainsi que des modèles, scripts et outils. X X

Publication pour des clients

Prend en charge un large éventail de clients, notamment ArcGIS Desktop, ArcGIS Explorer, ArcGIS for AutoCAD, et des applications basées sur des navigateurs web. X X

Gestion des images

Supporte un système complet de gestion des images permettant la mise à disposition de volumes d'images importants, exploitables sur des clients bureautiques, Web et d'imagerie. X X

Fonctionnalités d'application Web



Comprend des outils et des tâches, dont le zoom et les déplacements latéraux, l'identification d'entités, la mesure des distances, la localisation d'adresses, les requêtes et les recherches attributaires. X X

Outils de développement d'applications

Prend en charge les composants .NET et Java ADF, ainsi que les API ouvertes pour REST, Javascript et Flex. Les composants Enterprise JavaBeans ADF sont disponibles uniquement dans l'édition Avancée. X X

Analyse spatiale avancée

Intègre la modélisation et l'analyse spatiales avancées, avec notamment l'analyse d'aptitude, le calcul remblais/déblais, les lignes de visées, la modélisation de terrain. X

Fonctionnalité de mise à jour de données géographiq ue en mode Web

Prend en charge des tâches de modification spatiale pour les applications, par exemple l'ajout, la modification et la suppression d'entités cartographiques telles que les points, les lignes et les polygones. Offre des fonctionnalités de mise à jour web avancées (capture, etc…) X

Outils de développement d'applications nomades

Comprend une application nomade prête à l'emploi et configurable qui permet aux équipes d'exécuter, à distance, des requêtes et des mises à jour dynamiques des données du serveur. Administrée à partir d'ArcGIS Server, elle s'intègre parfaitement aux GPS et aux systèmes d'entreprise. X

Fonctionnalités des applications SIG nomades

Propose des outils, dont un kit de développement logiciel (SDK), permettant de gérer et de déployer des applications personnalisées, destinées à être utilisées sur des dispositifs nomades. Les applications nomades peuvent être déployées sur des appareils dotés de Windows CE ou Windows Mobile avec .NET Compact Framework 2.0, ou sur des PC dotés de Windows XP ou Vista avec .NET Framework 2.0. X

Du tableau précédent, il ressort qu’il est nécessai re de disposer du niveau « advanced » pour mettre à jour les données du serv eur à l’aide d’une application web ou mobile. Il faut également savoir que l’éditi on concurrentielle de données suppose que les données sont stockées selon un mode d’archivage compatible, en l’occurrence un SGBD. La création des ressources (c arte, geodatabase) publiables sous forme de services suppose donc l’installation d’ArcSDE pour le SGBD choisi (Oracle, SQL Server, PostGreSQL) . En résumé, il faut retenir qu’ArcGIS Server consist e en un ensemble d’outils permettant le stockage de ressources, l’administrat ion de ces ressources et leur déploiement à travers des applications webs. La mise en œuvre d’ArcGIS Server s’inscrit donc dan s un processus à trois temps :

• L’élaboration de ressources SIG • La publication des ressources en tant que services

• La consommation des services à l’aide d’une applica tion cliente.



faisant intervenir des publics différents : créateu rs et administrateurs de ressources, développeurs webs, utilisateurs in fine On retiendra également que les avantages d’une solu tion SIG serveur sur une solution bureautique tiennent essentiellement aux p oints suivants :

• Centralisation des ressources • Facilité de partage des ressources • Maîtrise de l’actualité des données diffusées

Le lien http://www.esri.com/software/arcgis/arcgiss erver/demos.html donne accès à une galerie de sites webs développés à partir de la technologie ArcGIS Server ainsi qu’à des vidéos illustrant les principes du dévelop pement d’applications de webmapping avec ArcGIS Server.

I.3. Les applications mobiles Ces outils sont destinés aux équipes de terrain, qu i dans le cadre de leur activité sont amenées à créer, mettre à jour, afficher et év entuellement analyser des données géographiques ; le SIG mobile est toujours couplé à un GPS pour la géolocalisation à la volée des données numérisées. Il y a 2 types d’outils : ArcPad qui est un logicie l clé en main et ArcGIS Mobile un kit de développement permettant de développer de s applications nomades centralisées et synchronisées avec un serveur ArcGI S Server. Il est possible d’interfacer ArcPad avec une soluti on ArcGIS Server, permettant ainsi aux équipes de terrain de travailler en direc t sur les données hébergées par le serveur. La mise en œuvre d’une telle solution n écessite de publier les données à mettre à jour sur le terrain sous forme d’un serv ice de carte (document Arcmap) compatible pour un usage dans ArcPad. La création d ’un tel service nécessite l’ajout de l’extension ArcPad pour ArcGIS Server. L a mise à jour de données par des équipes de terrain suppose également un accès concu rrentiel à une même source de données, donc un stockage SGBD et un accès ArcSDE.

I.4. Les services web hébergés ArcGIS Online est un ensemble de services web de co ntenu (des données, des cartes et des globes) hébergés par des serveurs Esri que l ’on peut consommer dans un client bureautique ou bien dans une application web . Parmi les données proposées, on a par exemple un ré seau routier mondial, avec deux niveaux de détails : la rue pour l’Amérique du nord , le Japon et un certain nombre de pays européens ; le réseau autoroutier et princi pal ailleurs. On trouve aussi la couverture mondiale SRTM à 90m de résolution. Les services ArcGIS online sont diffusés avec la te chnologie ArcGIS Server. Il y a deux types de service : les services standard auxquels on peut accéder gratuitement et qu’on peut utiliser sans limitation au sein d’un e entreprise tant qu’on n’en tire pas un revenu et les services premium qui donnent accès au niveau de détail le plus grand. Pour accéder aux services, se connecter au serveur ArcGIS Server à l’aide de l’url ci-dessous (Arccatalog)



Les produits ArcGIS ont la capacité à exploiter d’a utres services web hébergés que ceux publiés par ArcGIS Server. C’est notamment le cas pour les services ArcIMS (Geography Network) et tous les services diffusés s elon les normes OGC. L’illustration suivante montre une connexion WMS au serveur de cartes du BRGM (http://ogcpublic.brgm.fr/geologie? ).



II. Présentation des différents types de développement. La gamme d’applications ArcGIS offre plusieurs poss ibilités de développement. Toutes les applications ArcGIS sont conçues à parti r des mêmes composants : les ArcObjects, lesquels portent les fonctionnalités SI G. Lorsqu’on développe autour d’un produit ArcGIS on est donc amené a priori à ma nipuler ces classes d’objets que sont les ArcObjects. Il s’agit donc de programmatio n orienté-objet. Il y a toutefois une différence fondamentale selon que l’on développe dans un contexte bureautique ou serveur. Dans le premier ca s, les objets sur lesquels on agit ont été instanciés en local par l’application bureautique : ainsi, un outil d’identification du bureau de poste le plus proche développé pour ArcMap agit sur les objets instanciés par l’application ArcMap, i.e . ceux chargés dans le document que l’on est en train de visualiser ; dans le secon d cas, les objets sont stockés sur un serveur distant qui doit veiller à partager ces objets entre tous les clients susceptibles d’y accéder. Le même outil d’i dentification développé pour un client web agit donc sur des ArcObjects distants. L’API ArcObjects n’est toutefois pas la seule API o uverte au développement. Il faut la considérer comme l’API de référence, celle qui d onne accès au système ArcGIS dans toute sa complexité. Il existe notamment dans le cadre du développement web, d’autres API, plus limitées mais plus simples d’emp loi, permettant la mise en œuvre rapide d’applications personnalisées. C’est le cas notamment des API Javascript, Silverlight et Flex mais aussi de l’API Web ADF.

II.1. Produits bureautiques Le SIG bureautique peut être personnalisé, soit en intégrant à l’interface standard d’ArcGIS bureautique de nouveaux outils, soit en re développant une toute nouvelle application.

II.1.1. Personnalisation et extension Ces développements utilisent l’API ArcObjects . C’est un ensemble de composants, développés selon la norme COM et que le développeur peut réutiliser pour développer ses propres outils. Il est possible d’utiliser les ArcObjets en VBA (Vi sual Basic pour Application) : le travail consiste alors à développer des macros e n Visual Basic dans l’environnement de programmation intégré à ArcMap, ArcSCene, ArcGlobe. N.B : Cette possibilité de développement intégré ex iste à l’identique dans les applications de la suite Office (Word, Excel, Acces s, …), la seule différence étant que l’on développe dans ces applications à partir d ’autres bibliothèques de composants. Il est également possible de créer de nouveaux outi ls à l’aide des environnements de programmation standard Windows : Microsoft Visua l Basic 6 ou 2005 (langage VB) et Microsoft Visual Studio (langage VB .NET ou C#) et de les intégrer à l’IHM des applications standards. Il existe une troisième option : c’est le développe ment d’outils de géotraitement à l’aide de Modelbuilder et d’environnement de progra mmation de scripts. Ce sont des environnements de développements intégrés à ArcTool box, l’IHM de géotraitement d’ArcGIS. Le développeur y accède à travers un ArcO bject particulier : le géoprocesseur.

II.1.1.1. Personnalisation avec VBA Le débutant doit commencer par là car c’est le moye n le plus rapide de réorganiser l’interface et de coder de nouvelles fonctionnalité s.



Sans écrire une seule ligne de code, il est possibl e de • Réorganiser les barres d’outils et les commandes qu ’elles contiennent • Ajouter de nouveaux outils déjà programmés sous for me de custom commands .

De nombreux outils complémentaires ( add-ons ou plug-ins ) peuvent ainsi être téléchargés et intégrés à l’IHM.

Pour aller plus loin, le développeur dispose dans A rcMap, ArcCatalog et ArcScene de VBA (Visual Basic pour Applications), un environnem ent de programmation intégré qui permet de développer sous forme de macros de nouvel les fonctionnalités. Le langage de développement est le Visual Basic (VB). Plusieurs choses assurent une prise en main relativ ement aisée :

• les bibliothèques ArcObjects sont chargées en mémoi re ; certains objets (le document, l’application) sont accessibles à travers des variables globales prédéfinies.

• la possibilité de créer sans programmer de nouvelle s commandes (boutons ou outils) et d’y attacher sous forme de code évènemen tiel la nouvelle fonctionnalité

• la possibilité de définir des IHM élaborées (à l’ai de des objets formulaires) et notamment d’y intégrer tout type de composants ( ActiveX)

• la prise en charge par la machine virtuelle VB de t oute une partie du code (désallocation mémoire)

• un environnement de débogage Pour sa simplicité de mise en œuvre c’est la config uration retenue à l’ENSG : elle permet aux étudiants de manipuler les ArcObjects da ns un environnement convivial. Les macros sont sauvegardées avec le document dans lequel elles sont définies. Il est donc facile de partager le code : il suffit de copier le document dans lequel il est stocké.



Le code n’est pas compilé mais interprété à l’exécu tion : cela signifie donc que ce mode n’est pas adapté à la programmation de traitem ents lourds. Par ailleurs ce mode intégré comporte certaines restrictions : on n e peut pas créer d’extensions de classe, ni de nouveaux modes de représentation cart ographique. Enfin, le code source est difficilement protégeable. Si l’on ne so uhaite pas diffuser son code, la seule solution c’est de le compiler avec un IDE sta ndard et de l’intégrer sous forme d’un composant binaire (DLL, exe, ocx) à l’IH M d’ArcGIS bureautique. Le site resources.esri.com regroupe toutes les info rmations utiles à la communauté de développeurs ArcGIS. Le débutant y trouvera, en complément du cours dispensé à l’ENSG, toutes les informations utiles à l’apprenti ssage du développement ArcGIS dans l’environnement VBA. Les principes sont exposé s, l’ensemble des classes ArcObjects, ainsi que les interfaces COM permettant de les utiliser sont décrits de manière exhaustive. Enfin, de nombreux codes source s, classés par thématiques (accès à une base de données, mise à jour de donnée s, calculs 3D, calculs réseau) sont fournis.



L’annexe 1 propose une introduction brève au dévelo ppement avec VBA. Un autre document, Introduction à la programmation en VBA sur ArcGIS , rédigé et diffusé par l’ENSG traite le sujet de manière détaillée.

II.1.1.2. Extension avec VB ou .NET Dans certaines situations, il est nécessaire d’util iser des IDE non intégrés tels Microsoft VB ou Microsoft Visual Studio qui vont pe rmettre au développeur

• de travailler sans restriction sur l’intégralité de s ArcObjects • de compiler son code

Le développement VB ou .NET permet de créer des IHM complètement relookées (fenêtres, boutons, barres d’outils), de programmer de nouvelles extensions logicielles (ex : l’extension ArcHydro dédié aux ca lculs hydrologiques, http://downloads2.esri.com/support/datamodels/Hydro /ArcHydro13.zip ) s’intégrant à l’IHM standard (sous forme d’une barre d’outils pou r Archydro), mais aussi de personnaliser le modèle ESRI de géodatabase à trave rs la programmation d’extensions de classe . Les extensions de classe permettent entre autres d’exploiter pleinement le modèle orienté-objet en implémentant le comporte ment des entités de la géodatabase en réaction aux évènements de mise à jo ur (création, modification, destruction d’entités). La compilation du code présente deux intérêts majeu rs:

• ne pas diffuser le code source • améliorer les performances à l’exécution.

Les extensions ainsi programmées doivent être publi és sous forme de DLL ; ces nouveaux composants s’intègrent à l’IHM d’ArcGIS à l’aide de la boîte de dialogue ‘Personnaliser’ sous forme de custom commands , ainsi qu’on l’a déjà mentionné au paragraphe précédent. Il est également possible de recréer une nouvelle a pplication, c'est-à-dire de recompiler tous les Arcobjects en y intégrant ses p ropres développements. On recrée dans ce cas un nouvel exécutable (exe). ArcGIS est fourni avec des kits de développements ( pour Microsoft VB6 ou VB 2005 et pour Microsoft Visual Studio 2005) qui facilitent l a création de projets. Contrairement au développement VBA, il faut charger en mémoire (ou référencer) chacune des bibliothèques d’ArcObjects utiles. En annexe à ce document (annexes 2 et 3), vous trou verez un guide pour développer un composant en VB ou VB.NET



N.B : les ArcObjects sont des composants COM ; l’en vironnement .Net (le .Net framework) ne travaille pas directement avec ces co mposants mais avec des assemblies fournies par Esri, qui encapsulent de manière inte lligible pour lui la ressource COM. Cette couche supplémentaire ne dimin ue pas de manière significative les performances à l’exécution. Là encore, le site des développeurs d’ESRI, http://resources.esri.com/arcgisdesktop/dotnet/inde x.cfm , propose des éléments permettant au débutant de démarrer efficacement.

II.1.1.3. Développement d’outils de géotraitement L’environnement de géotraitement d’ArcGIS comprend

• une bibliothèque d’outils (ArcToolBox) • une application de modélisation graphique de proces sus (Modelbuilder) • un environnement d’exécution par ligne de commande • un environnement de création et d’exécution de scri pts (Python entre autres).

Ces éléments fonctionnent ensemble, de sorte qu’il est possible de développer de nouveaux outils en Python et de les intégrer à ArcT oolBox ou encore de créer graphiquement un outil avec Modelbuilder et le modi fier ensuite dans l’environnement de script. Tout utilisateur d’Arcgis est un consommateur poten tiel d’outils de géotraitement. Chaque opération de géotraitement consiste à transf ormer une donnée en entrée pour obtenir une nouvelle donnée en sortie. ModelBuilder et les scripts permettent de créer des processus composés de plusieurs opérations et ainsi d’automatiser les séquences en question. Les tâches à



automatiser sont en fait très variables. Cela va de simples opérations de gestion de données (copie, conversion) à de l’analyse élabo rée ; citons en guise d’exemple

• les conversions d’un format de données à un autre • la gestion des systèmes de référence • le calcul d’itinéraires sur un réseau de transport • le calcul de propagation d’un feu de forêt • la mise en évidence de regroupements dans une distr ibution de données

spatiales • la recherche de zones propices aux glissements de t errain • l’évaluation d’un aléa (inondation, incendie)

II.1.1.3.1. ModelBuilder

ModelBuilder permet de créer des modèles graphiquem ent par glisser-déposer d’outils et paramétrage de chaque traitement. Les modèles les plus simples consistent en une chaî ne linéaire de traitements, les données en sortie d’un traitement étant réinjecté e n entrée du suivant et ainsi de suite. Le site web d’aide d’ESRI vous propose de créer un premier modèle simple : http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm ?TopicName=Creating_a_simple_model ModelBuilder est un vrai environnement de programma tion et ce à plusieurs titres :

• il manipule les données à l’aide du concept de variable (les variables données et les variables valeur ; les premières stockent les données géographiques en entrée-sortie des outils de géotra itement, les secondes stockent les autres informations utiles aux outils) . Ce mécanisme permet de développer des processus de traitement paramétrable s, capables d’agir sur des données différentes, dans des conditions éventuelle ment différentes.

• Les variables sont typées • il offre toutes les structures de contrôle de la pr ogrammation structurée :

conditions, boucles Développons ce dernier point : s’il est vrai que ce rtains modèles peuvent être décrits simplement sous forme d’un enchaînement lin éaire d’opérations, c’est loin d’être toujours le cas.

C’est notamment le cas, lorsqu’une des données tra itée par le modèle est en entrée de deux sous-processus (voir ci-dessous) : il y a a lors deux branches dans lesquelles vont s’exécuter des traitements. Ces 2 b ranches peuvent éventuellement produire de nouvelles données elles-mêmes en entrée d’un autre sous-processus (voir toujours ci-dessous). L’ensemble des traitements do it donc s’exécuter dans un certain ordre.



ModelBuilder depuis la version 9.2 propose plusieur s mécanismes répondant à ces problèmes. A ce titre, on peut citer

• le concept de précondition : permet de spécifier qu’un outil doit être exécuté avant un autre

• le concept de condition : permet de gérer des séquences du type if condition1 then action1 else action1 end if .

• le concept de boucle ou de traitement répétitif. • Le concept de feedback : permet de réinjecter la sortie d’un modèle

itératif en entrée de ce même modèle à l’itération suivante Ce dernier mécanisme permet de créer des outils de simulation, illustrant la dynamique d’un territoire ou d’un phénomène géograp hique.

En résumé, les modèles peuvent être étonnamment com plexes (cf. http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm ?TopicName=%5BA_complex_model%5D) à tel point qu’il est souvent intéressant de déco uper le modèle en sous-modèles puis de créer un modèle de haut niveau qui appelle chacun de ces sous-modèles.



II.1.1.3.2. Les scripts de géotraitements

En complément de ModelBuilder, ou bien en alternati ve, il est possible de développer un modèle de géotraitement sous forme d’ un script. La plupart des langages (Python, Jscript, VBScript, Perl) sont com patibles, toutefois c’est Python qui a la préférence d’Esri et des développeurs ArcG IS en général : en effet sa simplicité et sa rigueur syntaxique, la richesse de ses bibliothèques (tous les domaines scientifiques produisent du code Python), le fait qu’il soit indépendant d’une plateforme sont autant d’atouts. Les scripts utilisent le géoprocessor : il s’agit d’un ArcObject, qui regroupe à la fois tous les géotraitements d’ArcGIS (extensions c omprises) mais aussi tous les paramètres d’environnement de ces traitements. N.B : le géoprocessor peut également être invoqué depuis VBA. Il est donc possible de créer des traitements avec ModelBuilder ou Pytho n et de les exécuter depuis une IHM développée en VB. Pour cela il suffit d’instanc ier le géoprocessor à l’aide de la fonction CreateObject , qui est la fonction utilisée en VB pour créer une instance dans une classe quelconque pourvue qu’elle implémente la norme COM

set gp = CreateObject("esriGeoprocessing.GpDispatch .1")

puis d’invoquer le traitement voulu gp.traitement param1, param2 Un diagramme présente le géoprocessor ainsi que tou s les objets dérivés qui peuvent être instanciés à partir de ses méthodes. Ce diagramme peut être consulté ici en ligne : http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm ?TopicName=Geoprocessor_Programming_Model .

N.B : contrairement aux diagrammes ArcObjects qui sont abordés au chapitre suivant il ne s’agit pas de modèles UML ; les flèches relia nt les classes indiquent simplement la possibilité d’instanciation entre les 2 structures et non des liens structurels au sens relationnel. Le langage Python est un langage de script de haut niveau qui propose tous les concepts de la programmation structurée.



Le code Python est structuré en modules et il est p ossible de charger ces modules lorsqu’on en crée un nouveau : c’est l’instruction import familière aux développeurs. Les commentaires sont précédés du car actère #.

Une des caractéristiques est l’utilisation du carac tère tabulation comme élément du langage. Là où dans la plupart des langages, l’ind entation n’est qu’une convention d’écriture destinée à améliorer la lisibilité du co de, ici elle a pleine valeur : si on n’indente pas le contenu d’une boucle for (d’ une condition if, d’une procedure), celle-ci ne sera pas exécutée. Pour le reste, il s’agit d’un langage à part entière dont la maîtrise requiert une phase d’ apprentissage. Le site officiel http://www.python.org/ dispose de toutes les références nécessaires. Une fois le script codé et la syntaxe du code valid ée, il est possible de l’intégrer en tant qu’outil à ArcToolBox et donc de l’utiliser comme n’importe quel outil de géotraitement. A souligner enfin

• que les performances à l’exécution sont moindres qu e pour du développement en mode compilé mais sensiblement les mêmes que pour d u code VB interprété par VBA.

• il y a une large communauté de développeurs de scr ipts Python et on peut trouver sur internet de nombreux outils tout faits : le site edndoc.esri.com met notamment à disposition de nombreuses ressource s à la rubrique Code Exchange (ArcScripts)

Le débutant trouvera sur le site resources d’ESRI t out ce qu’il faut pour s’initier au développement de modèles ou scripts de géotraite ment (http://resources.esri.com/geoprocessing/).

II.1.2. Création d’applications Il s’agit ici de créer une application SIG original e (un progiciel), taillée sur mesure pour un besoin précis. Ces développements répondent à 2 besoins

• remanier totalement l’IHM d’ArcGIS bureautique de f açon à simplifier l’accès d’un utilisateur novice à des fonctions SIG.

• marier certaines fonctionnalités SIG, telles la vis ualisation sous forme de cartes ou encore la capacité à rechercher des infor mations sur critères spatiaux à d’autres types de traitements (traitemen t de textes, tableur, statistiques, simulation) pour obtenir par exemple une application d’aide à la décision ou de gestion opérationnelle.

• Ce type de développement utilise ArcGIS Engine , un produit consistant en un run-time et une bibliothèque complète de composants SIG de haut niveau qui peuvent être utilisés par le développeur pour élaborer son appli cation personnalisée. L’utilisateur final de l’application n’a pas besoin de licence « ArcGis bureautique » : c’est le run-time qui lui permet d’ exécuter son application.



Il est possible de travailler avec des IDE Windows (COM ou .NET), mais aussi avec des IDE Java, tels Eclipse et JBuilder.

Le développement de l’IHM de l’application est rela tivement aisé puisque le développeur dispose de 7 controls de haut niveau (c ontrols Active X pour l’API COM, controls Windows .NET pour l’API .NET) :

• map control • pagelayout control • reader control • globe control • scene control • table of contents control • toolbar control

Pour le reste, le développement des fonctionnalités repose sur l’utilisation des composants ArcObjects comme vu précédemment. A noter qu’il est également possible de développer avec ArcGIS Engine une application cliente qui accède aux services publiés par un serveur SIG (qui utilise la technologie ArcGIS Server ou une autre).

II.2. ArcGIS Serveur

II.2.1. Utilisation de l’assistant Nous avons vu précédemment que l’application Manager d’ArcGIS Server permet de créer un client web sans développer une seule ligne de code.



Manager permet en effet de se connecter à des servi ces de carte hébergés soit sur le serveur ArcGIS local soit sur un serveur ArcGIS distant soit encore sur un serveur ArcIMS, ArcWeb ou bien WMS. Une fois les connexions vers les ressources établie s, Manager permet de régler les paramètres de publication (informations attributair es retournées par une requête résultat), choisir les outils, donc le type d’inter activité, et de mettre en page les éléments inhérents à la cartographie (barre d’é chelle, pavé de légende, etc…).

L’application créée par Manager est stockée dans le répertoire InetPub du serveur IIS : il s’agit d’un ensemble de fichiers codés pou r l’essentiel en asp et pour partie en Javascript. Cette application est codée s elon les standards du web 2.0 : elle utilise donc la technologie Ajax pour les écha nges d’informations entre le client et le serveur, notamment en ce qui concerne le rafraîchissement de la vue cartographique consécutivement aux différentes acti ons utilisateurs (changement d’échelle, modification de la visibilité des couche s, recherche d’objets).



Cela étant, on peut très rapidement avoir envie d’a ller au-delà de ce type d’application et ce pour plusieurs raisons :

• le manque de fonctionnalités : dans la vue ci-dessu s, mis à part les outils standards de navigation, il n’y a qu’un outil « mét ier » permettant la recherche d’un hôpital par son nom. On aurait pu pr oposer autre chose en standard mais le manager a ses limites. Ainsi, par exemple, un outil de recherche de l’hôpital le plus proche d’un lieu don né n’existe pas en standard.

• Le design ne correspond pas à ce qu’on souhaite • On aimerait créer une application mashup avec d’aut res ressources que celles

citées précédemment, en particulier avec les donnée s de fond de plan tirées des banques Google ou Virtual Earth.

Il convient alors de développer une application ori ginale. Le centre de ressources d’ESRI propose en ligne de nombreux éléments pour s ’initier aux différentes formes de développement. Un lien direct vers le point d’en trée dans le site est fourni pour chacune des rubriques dans ce qui suit.

II.2.2. APIs Javascript lien vers le centre de ressources pour l'API Javasc ript



C’est le bon outil pour celui qui débute en dévelop pement de solutions de webmapping autour des technologies ArcGIS. C’est au ssi la bonne solution si le cahier des charges n’impose pas de développer des f onctionnalités très avancées. L’API est libre de droits : on peut donc l’utiliser à volonté pour utiliser des ressources mises à disposition par des serveurs Arc GIS. Il est de plus inutile de télécharger quoi que ce soit : pour l’utiliser, il suffit de pointer sur un serveur Esri. Comme son nom l’indique, l’API Javascript permet d’ interagir avec les ressources serveur par l’intermédiaire de code Javascript, s’e xécutant côté client. Pour mémoire, la philosophie d’une solution Javascript c ’est de donner la possibilité au navigateur de réagir aux évènements provoqués par l ’utilisateur sur la page. Les évènements sont par exemple le clic sur un bouton d e commande, la sélection d’une entrée dans une liste déroulante, le déplacement du centrage d’une carte … Couplé à la technologie AJAX (Asynchronous Javascript and XM L), Javascript permet de programmer la réaction aux évènements en conservant une bonne fluidité de navigation (pas de rechargement de tous les élément s de la page web). Tout comme les API Google Maps ou Virtual Earth, l’ API d’Esri permet d’intégrer dans une page web des services de type carte , géocodage , géotraitement ou géométrie et de gérer le contenu de la carte ainsi que les in teractions avec l’utilisateur . Toutes les données peuvent être issues du même serv eur ou bien de serveurs différents. Il est notamment possible d’accéder à d es serveurs tiers pour les données de fond de plan. De nombreuses applications de webmapping fonctionnent sur ce principe : superposition de données métier sur d es fonds de plan standards (cartes topographiques ou orthophotographies). Par nature, cette API est faite pour consommer des services ArcGIS Serveur, et parmi eux signalons les services arcgisonline (http://server.arcgisonline.com/ArcGIS/rest/service s) proposant des fonds de carte d’extension mondiale de toutes sortes. Certaines do nnées sont en accès libre, d’autres font l’objet d’une tarification. A noter q ue tous les exemples d’application proposés par le centre de ressources utilisent ces services.



L’API permet également des consommer d’autres servi ces et notamment des services OGC. L’API communique avec les serveurs à l’aide du prot ocole Rest : pour accéder à une ressource (ou service) avec l’API, il faut donc con naître l’url de cette ressource. Le meilleur moyen d’identifier cette url, c’est de lister les informations relatives aux services hébergés par un serveur ArcG IS à l’aide de l’url http://<nom du serveur>/ArcGIS/rest/services/ vue précédemment. En retour, le serveur renvoie sa réponse sous forme de chaînes JSON (Javascript O bject Notation). N.B : JSON est un standard d’échange de données en mode texte. C’est une alternative à XML. De par sa nature, JSON est parti culièrement recommandé dans le cadre d’une interaction avec un programme Javascrip t. Les données JSON sont en effet parsées environ 100 fois plus vite que les do nnées XML. Suit le contenu en JSON de la recette d’une tarte aux fruits { « tarte » : [ {« ingredient » : « pomme », « quantité » :500g}, {« ingredient » : « beurre », « quantité » :250g} , {« ingredient » : « farine », « quantité » :250g} , {« ingredient » : « sucre », « quantité » :250g} ] } Les données sont structurées sous forme de tableaux de type Javascript. Les mêmes données en XML seraient formatées comme suit : <tarte> <ingredient nom= « pomme » quantité= « 500 » /> <ingredient nom= « beurre » quantité= « 500 » /> <ingredient nom= « farine » quantité= « 500 » /> <ingredient nom= « sucre » quantité= « 500 » />



</tarte> A priori les deux formats semblent comparables. Il faut néanmoins se rappeler qu’un document XML s’accompagne d’éléments annexes (DTD, schéma, namespaces …), ce qui explique la différence au parsage. Le mécanisme de communication intègre Ajax, i.e. f onctionne en mode asynchrone permettant l’échange d’informations en tâches de fo nd entre le client et le serveur. L’API prend totalement en charge tous ces aspects de la communication client-serveur; elle met à dispositio n du développeur des objets chargés d’émettre les requêtes vers des urls et d’e xploiter les chaînes JSON sans que celui-ci ait à rentrer dans les détails de ces mécanismes. Ces objets n’ont pas été développés par Esri, ils font partie d’un kit d e développement Javascript open source plus générique sur lequel l’API est construi te. Ce kit est le Dojo . Le Dojo permet avant tout de s’abstraire des partic ularités propres à chaque navigateur et donc de pouvoir écrire un code généri que, interprété par tous les navigateurs. Il permet également de disposer de fon ctions optimisées pour toutes les plate-formes. Le code produit avec le Dojo (ou un autre kit comme Prototype ) est donc plus synthétique et l’application plus rap ide et plus stable. Un autre avantage, c’est de pouvoir utiliser des composants déjà programmés : ce sont les widgets (ou Dijits ). Ces derniers permettent d’étendre les controls s tandard disponibles en HTML. Ainsi, avec le widget DatePicker il est très facile d’ajouter un outil de saisie de date se présentant sous forme d’un calendrier. Ou encore des listes déroulantes que l’on peut trier, des tableau x ( DataGrid ) avec des colonnes triables, etc… Il est nécessaire de connaître un ce rtain nombre de fonctions Dojo pour interagir avec les serveurs ArcGIS dans le cad re de cette API :

• Dojo.require : permet de charger une ressource Java script. Les ressources figurent dans le tableau suivant

ressources usage esri.map Map, geometry, graphics, and symbols esri.layers.agsdynamic Couche de données créées

dynamiquement par le serveur esri.layers.agstiled Couches de données pré- calculées et

mises en cache sur le serveur esri.tasks.find Find task esri.tasks.geometry Geometry task esri.tasks.gp Geoprocessing task esri.tasks.identify Identify task esri.tasks.locator Locator task esri.tasks.query Query task esri.toolbars.draw Draw task esri.toolbars.navigation task Navigation task

• Dojo.addOnLoad(init) : permet d’exécuter du code un e fois que la page a été

chargée complètement (ici on déclenche la fonction init ) • Dojo.connect(maCarte, « onLoad »,maCarteLoadHandler ) : permet de définir un

listener (écouteur) en relation avec un évènement p ortant sur un objet ou un élément de la page. C’est l’équivalent des fonction s Javascript addEventListener et attachEvent.

• Dojo.ById(« monControlInput »).value = « texte à st ocker ». Permet d’atteindre un élément de la page par son nom.

Le manuel de référence en ligne sur le dojo est une mine précieuse d’informations pour aller plus loin. Sa lecture s’impose pour tire r le meilleur parti de l’API Javascript (http://resources.esri.com et http://dojotoolkit.org ). L’API existe également sous forme d’extensions pour les API Google Maps et Virtual Earth. Ces extensions permettent d’intégrer des don nées de type carte servies par des serveurs ArcGIS aux couches de base Google ou M icrosoft : c’est ce qu’on appelle créer un mashup, i.e. une composition cartographique (sur le web) à partir de plusieurs sources. Ces extensions permettent aus si d’exploiter des services de géotraitement, de géocodage et d’afficher les résul tats sur ces fonds de plan. L’API Google Maps offre en plus la possibilité de v aloriser sous forme de diagrammes statistiques les données attributaires d es données SIG à l’aide API



Google Chart mais aussi de diffuser largement son a pplication sous forme d’une mapplet. Il est enfin possible de télécharger sur le site re sources d’ESRI une application Javascript modèle, le Javascript viewer , intégrant de nombreux composants d’interface (http://resources.esri.com/arcgisserver/apis/javasc ript/arcgis/index.cfm?fa=codeGalleryDetails&scriptId=15987 ). Cette application peut être adaptée aux besoins de chacun par l’intermédiaire de plusieurs fichiers de paramètres ( config.xml notamment) permettant de modifier à la fois le cont enu (les couches de données) mais aussi l’IHM et tout ça sans programmer une seu le ligne de code !! Il s’agit d’une application riche exploitant pleinement les t echnologies du web 2.0 et qui s’apparente par bien des aspects aux applications F lex ou Silverlight.

S’il est vrai qu’un simple éditeur de texte peut su ffire à la création d’une application Javascript, il est toutefois préférable d’utiliser un environnement de développement, et notamment l’environnement Aptana Studio pour lequel Esri fournit un plug-in permettant de disposer des objets de l’A PI et donc de bénéficier de l’auto-complétion.

II.2.3. APIs Flex et SilverLight Avec Flex et Silverlight, on entre dans la concepti on d’applications web dites RIA ou Rich Internet Applications . Le but est de créer des IHM avec un niveau d’interactivité comparable à une application bureau tique. Les solutions Javascript, même avec les améliorations liées à la généralisati on d’Ajax n’offrent pas encore tout à fait cette fluidité et cette qualité d’inter activité avec les données. Toutefois, il existe des inconvénients : le navigat eur client ne suffit pas pour exécuter de telles applications ; il faut ajouter u n plug-in. Ce qu’on gagne en interactivité, on le perd en vitesse de connexion a u site.

II.2.3.1. API Flex L’API Flex pour ArcGIS est bâtie sur l’environnemen t Flex d’Adobe. Les solutions Flex/Flash sont la référence en matière de création d’animations. Cet environnement nécessite côté client un plug-in, Flash Player vers ion 10 et pour le développeur un



kit de développement Flex ( Adobe Flash Builder 4 ). Contrairement aux API précédentes, cette solution n’est pas gratuite puis que le kit de développement Flex est sous licence. Comparativement à l’API Javascrip t, l’API Flex permet de produire avec moins de lignes de code des applications plus belles et plus riches. Une application Flex est développée à l’aide des langages MXML et ActionScript . Ce sont les équivalents respectifs des langages HTML et Javascript . MXML permet donc de définir le contenu (controls) et la mise en page de l’application, tandis qu’ActionScript permet de coder le traitement des é vènements utilisateurs sur les controls. ActionScript est un langage orienté-objet tout à fait classique. Il y a différentes façons d’associer le code Actionscript aux tags MXML :

• En implémentant directement un des évènements géré par le tag

<esri:map load="Alert.show('map is loaded')">

• En utilisant des blocs <mx :Script> ou <mx :initial ize)

<mx:Script> <![CDATA[ import mx.controls.Alert; private function onMapLoad():void { Alert.show('Bonjour!'); } ]]> </mx:Script>

• En important une bibliothèque ou une classe ActionS cript

include "myextracode.as"; Le code doit ensuite être compilé en swf. Pour utiliser l’API il faut télécharger l’API (il s uffit de s’inscrire sur le site Esri puis de suivre ce lien ) et l’environnement de développement (Flex Builder proposé en libre téléchargement pour 60jours sur le site d’adobe ). Pour de plus amples informations consulter le centr e de ressources et le site d’adobe . Sur ce site, on trouve en particulier en téléchar gement l’application bureautique Tour de Flex qui illustre les capacités de cet outil et notamme nt en terme d’exploitation cartographique (rubrique mapping ). Signalons enfin qu’ESRI met à disposition une appli cation template, le Sample Flex Viewer que l’on peut télécharger sur le site resources.esr i.com. Cette application est développée de telle sorte qu’il est possible sa ns développer, i.e. en modifiant uniquement des fichiers de configuration xml (cf. config.xml ci-dessous), de visualiser ses propres données géographiques. L’out il est également livré avec une documentation développeur indiquant comment ajouter des widgets , i.e. des fonctionnalités. Il est alors nécessaire de regénér er le fichier compilé (swf) avec Flash Builder.



II.2.3.2. API SilverLight D’un point de vue technique, l’API est construite e n sur-couche de l’API SilverLight de Microsoft, laquelle est intégrée aux environnements de développement Visual Studio 10 et Visual Web Developer Express. P our l’utiliser, il faut donc avant tout télécharger l’API Silverlight (http://si lverlight.net/ ). Silverlight est la solution concurrente de Flash. Toutefois, il s’a dresse avant tout à la famille de développeurs Microsoft : en effet, une telle app lication est développée à l’aide des langages XAML et C# .Net . Là encore il s’agit d’une solution équivalente à HTML/Javascript ou encore MXML/ActionScript . XAML permet de définir le contenu et la mise en page de l’application, tandis que c# .Ne t permet de coder les traitements. Tout comme les APIs Javascript ou Flex, l’API Silve rlight permet de créer une application web consommant des services publiés par ArcGIS Server ; elle permet en outre de consommer des services Bing Maps. Une telle application web peut être exécutée sur n’ importe quel système d’exploitation (Windows, Mac, Linux). Le centre de ressources en ligne d’ESRI propose un tutoriel pour une prise en main rapide.

II.2.4. le Web ADF (Application Development Framework) Pour l’instant, les API que nous avons décrites son t des API qui dialoguent avec le serveur selon le protocole REST, i.e. qui déclenche nt des services exposés sous forme d’URL. C’est le client qui parse les réponses textes fournies en JSON. C’est lui qui symbolise et dessine les données « vecteur » qu’il reçoit. Il existe bien entendu la possibilité de créer une application web côté serveur, i.e. une application qui est exécutée essentielleme nt sur le serveur et pour laquelle le client se contente d’afficher ce qu’il reçoit.



Ce mode de développement permet de masquer le code source ; il permet également d’ignorer les limitations de sécurité imposées au d éveloppement client : un code javascript ne peut échanger des informations qu’ave c des ressources hébergées sur son propre domaine. Il permet enfin d’accéder à tou te la richesse fonctionnelle du SIG : l’API REST n’expose en effet que les fonction nalités les plus courantes

Avec une application web 3 tiers, il devient donc p ossible de proposer des traitements lourds (calculs) mais aussi de l’éditio n de données (saisie en base, mise à jour), notamment dans un contexte d’accès mu lti-utilisateurs. C’est le propos du Framework Web ADF. En fait, il y en a 2 : un pour l’environnement .NET et un autre pour l’environnement Java. Nous n’évoquerons ici que le Web ADF .NET, sachant que seuls les langages et environnement de développement chan gent entre les deux. Un framework, c’est un ensemble d’outils s’intégran t à un environnement de développement. Le Web ADF pour .Net s’intègre à Mic rosoft Visual Studio ; il consiste en

• Un template d’application web, accessible à partir de la boîte de dialogue de création de projet

• De controls web arcgis acessibles dans la boîte à o utils (ex : le control Map)

• D’une API, i.e. de bibliothèques programmées en ASP , toutes préfixées en ESRI.ARCGIS.ADF

Le principe de création d’une application web .Net à dimension spatiale avec cet outil est le même que celui du développement d’une application web .Net quelconque proposant un certain niveau d’interactivité : gliss er-déposer de controls sur un formulaire, paramétrage des propriétés des controls , programmation du code prenant en charge la réponse aux évènements (clic souris su r un bouton, …). La différence c’est qu’on manipule ici des objets de haut niveau tels une fenêtre Carte , une fenêtre contrôle des couches (ou table des matières selon la terminologie ArcGI S). Les applications développées avec le web ADF .NET s e déploient sur le serveur web IIS. Nous avons vu précédemment qu’ArcGIS Server est liv ré avec une application, le Manager , qui permet de créer un client web. Une telle appl ication est développée à partir du web ADF : c’est une application 3 tiers c omprenant essentiellement du code ASP. Il est possible de modifier le code créé ainsi dans Visual Studio et de recompiler l’application. Une autre solution consiste à créer une application dans Visual Studio à partir du template. Si on compile sans aucune retouche, on ob tient la même chose qu’avec le



Manager. L’annexe 5 explique cela. Pour plus d’informations se référer aux tutoriel s du centre de ressources. Une troisième solution consiste enfin à créer une a pplication de toute pièce à partir des composants de la boîte à outils. Le Web ADF permet de créer des applications qui int eragissent avec différents types de ressources : ArcGIS Server tout d’abord, ArcIMS ensuite, Virtual Earth, ressources OGC (WMS, WCS, WFS). Afin de programmer les interactions des Web controls avec les ressources, le développeur dispos e de plusieurs API : une API commune à toutes les sources qui regroupe les fonct ionnalités que l’on retrouve chez chacune d’entre elles (ex : obtenir une carte, obtenir les informations attributaires), des APIs propres à chacune des sour ces pour les fonctionnalités spécifiques (API ArcObjects par exemple pour calcul er un itinéraire optimisant une tournée ou encore pour des calculs qui exploitent l a 3D). Les samples du centre de ressources facilitent de ce point de vue la maîtrise des différentes API: ils sont préfixés par le nom de l’ API utilisée (ex : Common Custom EditorTask).

II.2.5. Résumé Nous avons évoqué une partie des développements pos sibles autour d’ArcGIS Server et de la consommation par un client de ressources dist antes, ainsi que le montre l’illustration suivante.



Il est notamment possible de développer à partir de s API SOAP et ArcObjects des services webs personnalisés, i.e. des ressources dé pourvues d’interface destinées à être consommées par une application. Le développeur peut donc non seulement concevoir des applications totalement originales ma is aussi concevoir des services qui vont au-delà de ceux proposés par ArcGIS Server en standard.



III. Le développement bureautique avec l’API ArcObjects

III.1. Les ArcObjects Les ArcObjects forment un ensemble de composants lo giciels, indépendants de tout système d’exploitation. Ces composants ont été codé s en C++ et compilés sous forme de DLL ; ils regroupent l’ensemble des fonctionnali tés SIG proposés par les produits de la gamme ArcGIS.

Ils ont été développés conformément aux prescriptio ns de la norme COM. C’est cette norme, entre autres, qui permet la réutilisation de s mêmes composants dans des contextes différents : bureautique ou serveur. Le développeur manipule les ArcObjects à l’aide de bibliothèques qui exposent les fonctionnalités des ArcObjects;



Ces bibliothèques regroupent les services par natur e : il y a celle qui propose les traitements relatifs à l’affichage de données, cell e qui s’occupe de l’accès aux données, … Certaines sont partagées par les différe nts produits (bureautique et serveur) ; d’autres sont propres à chacun (les bibl iothèques xxx UI sont propres à ArcGIS bureautique ; elles spécifient les composant s dotés d’une interface utilisateur). La bibliothèque System est celle de plus bas niveau, Geometry permet de manipuler la représentation graphique des entités géographiqu es, Geodatabase permet d’accéder aux données stockées sous forme d’une géodatabase, Server permet de se connecter à un serveur ArcGIS server et d’exploiter les ressour ces qu’il diffuse, ArcWeb permet d’accéder aux services web hébergés par les serveur s Esri, Carto permet la création et l’affichage de cartes, Network Analysis la création d’une topologie arc-nœud et son exploitation, Animation la création d’animations temporelles dans ArcMap, ArcScene et ArcGlobe, etc…

Il faut retenir que tous les produits ArcGIS sont c onstruits à partir des mêmes composants. C’est évidemment très intéressant pour l’éditeur de ces logiciels, mais ça l’est tout autant pour le développeur qui peut p rogrammer de la même manière quel que soit le contexte. Pour une description plus détaillée de ces objets, consulter ce lien .

III.2. La norme COM COM permet de développer un logiciel sous forme de composants, réutilisables qui plus est. Cette technologie qui présente évidemment de très gros avantages est aujourd’hui adoptée par tous les éditeurs de logici els. Elle permet de décliner au moindre coût toute une gamme de produits à partir d ’un socle commun ; elle permet aussi de faire évoluer avec souplesse tel ou tel as pect du logiciel sans le remettre en cause. ESRI a choisi COM il y a quelques années car c’étai t la technologie mature pour créer une application sur ce principe. C’est encore aujourd’hui la norme de



référence pour tout ce qui est bureautique. Dans le monde du web, les JavaBeans sont une technologie comparable. COM reprend tous les principes de la programmation orienté-objet et notamment la programmation à base d’interfaces . Selon ce principe, les propriétés et les méthodes des classes d’objets sont encapsulées derr ière des interfaces, ce qui assure un niveau de sécurité maximal. Le mécanisme d’accès à la fonctionnalité est alors le suivant : un client qui souhaite consommer une ressource émet une requête vers un serveur capable de la lui fournir. Le clie nt ignore tout de la façon dont sa requête est traitée ; il récupère l’information c’est tout. Dans les applications ArcGIS, les ArcObjects sont d es classes COM : les instances de ces classes peuvent donc jouer le rôle de serveu r COM, i.e. sont capables de fournir des services (afficher une couche, renvoyer le périmètre d’un objet surfacique) à des clients. Ces services sont spécif iés à travers des interfaces, avec lesquelles le client interagit. Il y a des mil liers de propriétés et méthodes ainsi exposées par les interfaces. Les ArcObjects sont à tour de rôle serveur et clien t selon la situation. C’est ce que montre le schéma suivant : imaginons que l’on s ouhaite modifier par programme le système de référence du bloc de couches de notre document ArcMap. Pour ce faire, on va attacher du code VB au document ArcMAP et on va demander à modifier la propriété système de référence pour l’instance de classe Map représentant le bloc de couches. Pour accéder à cette instance de classe Map il faut passer par une instance de classe intermédiaire : l’application Ar cMap. Au final, le client VB adresse une requête au serveur ArcMap qui lui-même devient client pour adresser une requête au serveur Map.

N.B : peu importe le langage dans lequel les compos ants ont été développés ; dans la mesure où ils implémentent les fonctionnalités p révues par la norme, les versions compilées de ces mêmes composants sont à m ême de dialoguer entre elles. L’objet et ses clients peuvent appartenir au même e space de processus, c’est le cas pour des objets de type DLL. A contrario, l’objet e t ses clients peuvent tourner dans 2 processus mémoires différents : c’est le cas avec les exe. Les 2 solutions présentent des avantages : les DLL se chargent plus rapidement en mémoire, mais les EXE fournissent une solution plus robuste : en cas de plantage du serveur, le client lui n’est pas affecté. Ex : quand on ouvre un document ArcMap qui consomme un certain nombre de services ArcObjects (liens vers des sources de données, repr ésentation graphique des objets, barres d’outils et extensions chargées), tous les c omposants utiles (dll) sont mis en mémoire dans l’espace du processus ArcMap. Pour une description plus détaillée de la norme COM , consulter ce lien .

III.3. Les interfaces

III.3.1. Définition Lorsque le développeur (le client) travaille avec l es ArcObjects, il n’accède pas directement aux classes d’objets (les serveurs) mai s communique avec elles à travers les interfaces qu’elles implémentent. Une interface peut être définie comme la spécificat ion d’un ensemble de propriétés et de méthodes qu’une ou plusieurs classes d’objets implémentent. Classes et interfaces sont respectivement le « what » et le « how » de la norme COM.



N.B : • Une interface n’est pas une classe : en effet, une interface ne peut pas être

instanciée puisqu’elle n’implémente rien elle-même • une interface n’est pas un objet ; c’est un regroup ement logique de fonctions

virtuelles qui servent uniquement à établir la comm unication entre un serveur et ses clients.

Une fois publiée, la signature d’une interface ne p eut plus évoluer. En revanche, il est possible à tout moment de modifier son implé mentation, qu’il s’agisse de corriger un bug, ou bien de redévelopper complèteme nt un algorithme : ces modifications nécessiteront simplement de recompile r les composants (dll) qui implémentent l’interface, les clients n’étant pas a ffectés par cette mise à jour. S’il s’avère nécessaire de publier de nouvelles fon ctionnalités, alors il s’impose

• De créer de nouvelles interfaces • D’implémenter ces interfaces par les composants exi stants ou bien par de

nouveaux composants Au fil des mises à jour logicielles, certaines inte rfaces tombent en désuétude (deprecated) : elles subsistent néanmoins afin que les clients qui les utilisent puissent continuer à fonctionner.

III.3.2. Un monde orienté-objet Les classes COM implémentent les fonctionnalités ex posées par une ou plusieurs interfaces : la fonctionnalité se retrouve ainsi encapsulée entièrement dans le composant logiciel. C’est le premier principe de l’ orienté-objet. Deux classes COM différentes peuvent implémenter la même interface, mais éventuellement de manière différente : c’est ce qu’ on appelle le polymorphisme , qui est le second principe de l’orienté-objet. C’est ce que montre le schéma suivant :

Enfin COM supporte le concept d’héritage entre classes ce qui est le troisième principe de l’orienté-objet.

IBirth

ITalk

IWalk

IDeath

Ifly

IBirth IBirth IBirth

ITalk ITalk

IWalk

IDeath

IWalk

IDeath IFly



III.3.3. L’interface IUnknown et les autres Tous les serveurs COM implémentent l’interface IUnk nown qui expose des fonctionnalités de bas niveau permettant au client

• de créer une instance, de la détruire (méthode AddRef et Release ). • de passer d’une interface à l’autre pour une même i nstance (méthode

QueryInterface ) En plus de cette interface IUnknown, les ArcObjects implémentent d’autres interfaces qui exposent les fonctionnalités SIG. Pa rmi toutes les interfaces implémentées, une joue le rôle d’interface par défa ut. Lorsqu’un client crée une instance, il accède à cet te instance à l’aide d’une variable pointeur qui référence une des interfaces implémentées par l’instance. N.B : on peut représenter de manière imagée un serv eur COM comme un cube, dont chacune des faces est une interface. Un client ne p eut voir qu’une face en même temps : c’est pourquoi lorsqu’il établit la communi cation, il obtient un pointeur vers une des interfaces. Toutefois, le client peut à tout moment faire pivoter le cube pour accéder aux autres faces du client. Il existe des interfaces de type Inbound et Outbound : les premières sont les plus communes, elles exposent des fonctionnalités implém entées par le serveur ; les secondes s’apparentent au mécanisme de callbacks : le serveur n’implémente pas les fonctionnalités, il s’en remet au client ; ces inte rfaces permettent notamment de gérer les évènements. Les interfaces peuvent hériter les unes des autres. Pour une description plus détaillée du concept d’in terface, consulter ce lien .

III.4. Développer avec les ArcObjects

III.4.1. Les diagrammes de classe C’est l’information de base, c’est aussi la clé du succès lorsqu’il s’agit d’utiliser les ArcObjects. Ces diagrammes UML sont décryptés (du moins en part ie) lors des séances de travaux dirigés. Ils permettent d’appréhender la structure d’ensemble du logiciel.

Ces diagrammes sont fournis au format PDF : on peut donc utiliser le moteur de recherche pour localiser une classe ou une interfac e donnée.

A ces diagrammes, s’ajoutent deux autres ressources complémentaires : • les browsers intégrés aux environnements de dévelop pements (VBA, VB6, .NET)

• le site edndoc.esri.com et son moteur de recherche Les modèles UML font état de 3 types de classes d’o bjets :



• La classe abstraite : elle ne peut pas être instanciée. Elle expose de s propriétés et méthodes génériques, communes à plusi eurs autres classes, qui structurellement lui sont reliées par un lien d’hér itage. Les classe Geometry, Layer et Dataset sont 3 exemples de classes abstraites : on ne peut pas créer d’instances Geome try, Layer ou Dataset ; en revanche, il est possible de créer une instance Point qui implémente les propriétés et méthodes spécifiées par Geometry (voi r schéma ci-dessous). De la même manière, on peut créer une instance RasterLayer qui implémente les spécifications de Layer .

• Les coclasses : ce sont les classes instanciables . COM peut donc créer des instances pour ces classes et les passer au client.

• Les classes simples : elles ne peuvent être instanciées que par

l’intermédiaire d’une instance d’une autre classe.

ex : la classe Feature , qui représente la notion d’entité, i.e. d’enregistrement dans une table géographique, ne pe ut être instanciée que si la classe FeatureClass l’est déjà. Ceci signifie qu’un client ne peut acc éder à un enregistrement d’une table que s’il dispose dé jà de la table).

Ces classes s’inscrivent dans un modèle objet : ell es sont reliées les unes aux autres par des liens

• D’héritage • De composition • D’instanciation • D’association

Les diagrammes font également état des interfaces i mplémentées par les classes. Les inbound et outbound interfaces sont différenciées. Les héritages d’int erface sont également indiqués.

III.4.2. Considérations sur l’utilisation des ArcObjects en environnement VB.



Les TD ont lieu à l’ENSG dans l’environnement VBA. Ce mode de développement intégré permet d’attacher un projet VB à un document ArcMap ; A l’intérieur du projet, le code est stocké dans des modules, des modules de cl asse et des formulaires. L’environnement VBA facilite le travail du développ eur, en ce sens que les ArcObjects sont déjà référencés. Par ailleurs la ma chine virtuelle VB qui exécute le code prend en charge tout ce qui est de l’ordre de la gestion mémoire : il n’y a donc pas à se soucier de désallouer les différentes variables objets. VB est un langage de programmation orienté-objet do té de tout ce qu’il faut pour programmer de manière structurée (variables typées, procédures, fonctions, tests, boucles, gestion d’erreurs, …). Il est utile de connaître un certain nombre de règl es :

• Forcer la déclaration des variables avec Option explicit en tête de chacun des modules

• Utiliser le mot-clé Dim pour déclarer une variable locale, et Public ou Private pour déclarer des variables globales (2 mots-clés pour signifier la portée de la variable globale)

• Ne pas utiliser le mécanisme de propriété par défaut : en effet, COM permet de définir une propriété par défaut parmi toutes le s propriétés exposées par une classe ; mais ça nuit à la lisibilité du code.

• Les paramètres des procédures et fonctions sont pas sés par défaut par référence. Il faut ajouter le mot-clé byval pour les passer par valeur.

• Pour accéder à une classe COM (notamment aux ArcObj ects), déclarer une variable pointeur sur une des interfaces implémenté es par la classe ; instancier ensuite votre variable à l’aide du mot c lé New.

Ex :

Dim pLayer as ILayer Set pLayer = New Featurelayer pLayer.Name « couche d’entités » Ne pas écrire même si VB l’accepte Dim pLayer as New FeatureLayer pLayer.Name « couche d’entités » La notation courte fait disparaître le principe de la communication à travers les interfaces.

• Pour accéder aux propriétés d’une classe COM, regar der le type de la

propriété. Si c’est une interface, déclarer une var iable en référence à cette interface et utiliser le mot-clé Set ; sinon déclarer simplement une variable du type indiqué.

Ex :

‘imaginons qu’on a déjà un pointeur sur l’instance de classe Actiview qui représente la fenêtre graphique d’ArcMap ‘on veut récupérer l’emprise (les coordonnées min e t max) de la zone actuellement cartographiée ; il faut travailler ave c une classe ArcObjects intermédiaire : la classe Envelope

Dim pEnv as IEnvelope Set pEnv = pActiveView.Extent Dim dblxmin as double



dblxmin = pEnv.XMin Dim dblxmax as double dblxmax = pEnv.XMax

• Pour accéder aux methodes d’une classe COM, regarde r si la méthode renvoie ou non une valeur. Si oui déclarer une variable du mêm e type.

Ex : ‘pour augmenter l’echelle d’affichage d’un facteur 2 pEnv.Expand 0.5, 0.5, true ‘pour dessiner un cercle à l’aide du control approprié Dim pCircle as IPolygon Set pCircle = MapControl2.TrackCircle



• Pour ajouter du code en réponse à des évènements co ncernant des controls personnalisés (ceux ajoutés par l’outil de personna lisation de l’interface dans ArcMap), remplir les squelettes de procédures générés automatiquement dans le projet VB.

• Pour coder les évènements associés à un ArcObject, déclarer une variable avec le mot clé WithEvents en tête de module

‘on déclare la variable pour écouter les évènements associés à la fenêtre active Private WithEvents m_pActiveViewEvents As Map ‘on instancie la variable Public Sub SetEvents() Dim pMxDoc As IMxDocument Set pMxDoc = Application.Document Set m_pActiveViewEvents = pMxDoc.FocusMap End Sub ‘on code la réponse à l’évènement Private Sub m_pActiveViewEvents_SelectionChanged() MsgBox "Selection Changed" End Sub

• Pour encapsuler des données dans des classes, décla rer les sous forme de

propriétés privées à la structure et implémenter su r la structure les méthodes Property Get, Property Set, Property Let qu’utiliseront les clients pour accéder en lecture/écriture aux données.

III.4.3. Pratique des concepts de classe et d’interface Imaginons que l’on souhaite décrire les concepts de démocratie et de dictature puis manipuler les structures ainsi décrites (les serveu rs) dans un programme client écrit en VB. L’analyse conceptuelle permet de dégager un certain nombre de propriétés et méthodes communes aux deux structures. Qu’il s’agis se d’une démocratie ou d’une dictature, on considère une entité « pays » qui a un nom, une population, un volume d’exportations et d’importations, une armée, une ba lance commerciale; ces données peuvent être regroupées dans une classe abstraite Pays . Certaines de ces données vont être implémentées de manière différente : si l ’on considère que l’effectif de l’armée peut se déduire proportionnellement à la po pulation d’un pays, on peut convenir que le rapport n’est pas le même selon qu’ il s’agit d’une démocratie ou d’une dictature. L’analyse révèle aussi des données propres à chacun e des structures: il faut par exemple considérer les concepts d’élection et de pé riodicité des élections pour une démocratie, celui de coup d’état pour une dictature . Sur la base de ces données, on a le modèle concept uel suivant qui décrit 3 classes : une classe abstraite Pays et deux classes instanciables Democratie et Dictature .



Ces 3 classes peuvent être créées en VB sous forme de modules de classe . Cela étant, la norme COM impose d’encapsuler l’accè s aux données (dans le modèle ci-dessus, la portée des données est publique). C’e st là qu’intervient la notion d’interface.

Pour créer les interfaces en VB, qu’utiliseront les clients de nos structures Democratie et Dictature , il faut créer 5 modules de classes :

• 3 pour spécifier chacune des 3 structures mises en évidence par le modèle conceptuel ; ce sont les interfaces IPays, IDemocratie et IDictature .

• 2 pour implémenter les structures instanciables de notre modèle conceptuel Les interfaces exposent les membres d’une structure : propriétés et méthodes ont une portée publique. Les classes implémentent ces m embres : ceux-ci ont une portée privée ; les propriétés en particulier sont lues ou modifiées avec des méthodes de type Get ou Set (property Get ou Set en VB).



ANNEXES

Annexe 1 : personnalisation Arcgis bureautique en VBA Depuis ArcMap (ou ArcCatalog) on ouvre l’éditeur VB avec Alt+F11. Tout document ArcMap comporte un projet VB Project ; il est enregistré avec le document lorsqu’on sauvegarde celui-ci. En VBA (VB en général), le code est structuré dans des modules, des modules de classe et des formulaires. Ces éléments sont eux-mê mes stockés dans des projets VB.

Un module est un ensemble d’instructions VB, struct urées sous forme de procédures et de fonctions. Un module de classe décrit une classe au sens orien té-objet du terme, i.e. spécifie et implémente un ensemble de propriétés et méthodes . (on utilise également les modules de classe pour créer une interface COM) Un formulaire est une IHM qui contient un certain n ombre de controls (boutons, liste déroulante) auxquels est associé du code évén ementiel.

Tout document comporte également un projet Normal qui est un template, contenant tous les éléments d’interface standards, ainsi qu’u n module nommé ArcID qui contient l’UID de chaque commande de l’application. Le code personnalisé est le plus souvent attaché au projet Project et non pas à Normal . Dans le cas contraire, le code sera commun à tous les documents ArcMap créés sur le poste de travail. Si on a ouvert le document ArcMap à partir d’un tem plate autre que Normal.mxt , un autre projet template apparaît également. Tous les documents Arcmap ou ArcCatalog contiennent un module de classe particulier nommé ThisDocument . Ce module représente le document, qui pour ArcMap est une instance de la classe MxDocument, pour ArcCatalog u ne instance de GxDocument. Une fois l’éditeur VB ouvert, il est possible d’ins érer de nouveaux modules, modules de classe ou formulaires. Le code attaché à chacun de ces éléments peut



être visualisé simultanément dans plusieurs fenêtre s. Il est possible de copier-coller du code d’une fenêtre à l’autre. Il est égal ement possible d’importer un élément de l’un des 3 types mentionnés depuis un fi chier enregistré sur le disque. Pour ajouter du code, on peut

• écrire dans le module de classe ThisDocument

• insérer un nouveau module

Un module (ou un module de classe, ou un formulaire ) comporte des instructions. Ces instructions sont stockées dans des procédures, cha cune étant du type sub , function ou property (les « getter » et « setter » pour lire et écrire l es données membres privées d’une structure) et chacune étant d’accès public ou private . Les procédures en accès private ne sont visibles qu’à l’intérieur du module dans lequel elles sont décrites. Un module comporte en outre des déclarations de var iable. Les variables peuvent être locales ou globales. Les locales ont une porté e limitée à celle de la procédure dans laquelle elles sont déclarées. Les g lobales quant à elles persistent tant que le programme tourne. Si on souhaite créer une IHM, on insére un module d e type formulaire , puis on fixe graphiquement le contenu de celui-ci en piochant pa rmi les controls proposés par la boîte à outils.

N.B : il est possible d’ajouter tout control référe ncé dans la base de registres. Ensuite, dans la fenêtre de code attaché au formula ire, on implémente parmi la liste des évènements attachés à chacun des controls ceux que l’on souhaite traiter. Pour protéger le code attaché à un document, i.e. p our empêcher tout utilisateur du document de le voir et donc de le modifier, il suff it de définir une protection par mot de passe avec un clic droit sur Project>Propriétés . Pour exécuter le code d’une procédure, placer le cu rseur dans la procédure puis exécuter. Une alternative consiste à ajouter à l’in terface du document ArcMap un



bouton personnalisé de type Custom Control>Button C ontrol et à déclencher le code en réaction à l’évènement clic sur ce nouveau contr ol. Il y a un environnement de déboggage : ajout de poi nts d’arrêt, instructions pas à pas, examen du contenu des variables. En VBA, il y a 2 variables globales d’application, qui peuvent être utilisées par tout module et toute procédure : Application et ThisDocument . La 1 ère permet de manipuler l’instance de la classe Application en cours, i.e. l’ArcMap actuellement utilisé ; la seconde permet de manipuler le documen t ArcMap ouvert, en tant qu’instance de la classe MxDocument. Pour de plus amples explications, ainsi qu’une pris e en main approfondie des ArcObjects se référer au document ENSG « Introduction à la programmation en VBA sur ArcGIS » (document word).



Annexe 2 : extension ArcGIS bureautique avec Microsoft Visual Basic 6 N.B : Il est utile au préalable d’installer un certain nombre d’adds-ons fournis par Esri, qui facilitent le travail de programmatio n. Afin de charger dans l’environnement de développement VB tous les adds-i n, il suffit d’exécuter registervbaaddins.exe que l’on trouve dans le répertoire addins du kit d e développement. Pour créer un composant COM, avec Visual Basic, il suffit de créer un ActiveX Dll. On obtient un projet VB avec un module de classe.

Paramétrer comme suit les propriétés d’instanciatio n :

Charger ensuite les bibliothèques ESRI requises pou r le développement (aller dans Projet>References). Il est en effet nécessaire de référencer les ArcObj ects (classes, interfaces) qui n’ont aucune raison d’être connus de l’IDE. Selon c e que l’on veut programmer, il faut charger un plus ou moins grand nombre de bibli othèques. Dans tous les cas, on charge au moins la bibliothèque Esri System Object ( esriSystem.olb ) ainsi que la bibliothèque carto ( esricarto.olb ), les bibliothèque ArcMap , ArcMap UI , Framework , SystemUI . Si on travaille avec les objets de l’extension Sp atial Analyst, il faut charger Esri Spatial Analyst Object.



Le module de classe doit ensuite implémenter une ou plusieurs interfaces. C’est l’instruction Implements qui indique quelles sont l es interfaces implémentées. Il faut donc coder toutes les méthodes attachées à la (ou les) interface(s) en question, sinon le programme plante à l’exécution : c’est le principe stipulé par COM concernant l’implémentation des interfaces de t ype Inbound . Pour certaines interfaces, ça peut être relativemen t fastidieux. Cela étant, un des add-ons ajoutés crée automatiquement les prototypes des méthodes à implémenter.

ex : pour créer une nouvelle commande, intégrable à l’interface d’ArcMap, le module de classe doit implémenter l’interface esriSystemUI .ICommand ;



L’Esri Interface Implementer permet d’obtenir les p rototypes de méthodes suivants :

Il faut implémenter de manière obligatoire : • ICommand_enabled (renvoie true) • ICommand_Checked (renvoie false) • ICommand_OnCreate (pour récupérer dans une variable l’instance de la classe

Application à laquelle la commande est attachée) • ICommand_OnClick pour coder la fonctionnalité

L’exemple suivant montre le code nécessaire à la cr éation d’un composant qui affiche le nom du bloc de couches actif du document arcmap auquel il est attaché.



Ne pas oublier de désallouer la mémoire pour les va riables globales dans la méthode class_terminate du module de classe. Il faut enfin compiler le code pour fabriquer la dl l : aller dans Fichier>créer xxx.dll. Si on souhaite définir une icône pour la commande, on peut créer un formulaire contenant un control image.



il faut ensuite charger ce formulaire lorsqu’on ins tancie la commande (méthode class_initialize) et récupérer l’adresse de l’image dans la méthode Bitmap de l’interface ICommand. C’est un nouveau composant prêt à l’emploi. Il peut être chargé dans ArcMap à l’aide du menu Outils>Personnaliser>Ajouter depuis un fichier.



Annexe 3 : extension ArcGIS bureautique avec Microsoft .Net Ouvrir Microsoft Visual Studio 2005.

En VB ou C# (dans tout ce qui suit les codes sont é crits en VB), créer un nouveau projet MaCommandeDotNet en utilisant le template Argis Desktop Class Library (ArcMap) fourni.

Ajouter ensuite au projet les références vers les . Net assemblies (les bibliothèques utiles) qui vont nous permettre de dé velopper notre commande à partir des composants ArcObjects.



Sélectionner puis ajouter les assemblies suivantes : ADF, ArcMapUI, Carto, Framework, Geometry, System, SystemUI.

L’assistant crée alors le nouveau projet. On ajoute manuellement une référence supplémentaire vers l’assembly System.Drawing à l’aide de Projet>Ajouter une référence .

Détruire le fichier class1.vb qui a été créée automatiquement par l’assistant. O n va utiliser un template pour créer une nouvelle cla sse de type Commande à l’intérieur de notre projet. N.B : le projet qui a été créé est de type bibliothèque de classes .



Cliquer droit sur le projet (dans l’explorateur de projets) et ajouter un nouvel élément

Parmi les templates proposés, choisir Base command et appeler la nouvelle classe ZoomsuruneCouche.vb.



Choisir de créer une commande de type Desktop ArcMap .

Dans l’explorateur de projet, détruire l’icône qui a été ajoutée automatiquement par l’assistant. Ajouter ensuite une référence vers le fichier layer_6.bmp stocké dans le \bin\icons du répertoire d’installation d’ArcGIS. Sélectionne r le fichier ainsi ajouté et modifier les propriétés Action de génération (ressource incorporée) et Nom de Fichier (ZoomsuruneCouche.bmp). Si on observe le code généré automatiquement par l’ assistant, on voit que :

• La classe hérite de la classe BaseCommand (laquelle est une classe abstraite) • La classe comporte 4 membres

o Une propriété, m_application , qui est une référence vers l’application à laquelle la commande qu’on développe est intégrée

o Un constructeur o 2 méthodes héritées de BaseCommand et surchargées, OnCreate et OnClick

• Le code est pré-rempli mais doit bien entendu être complété. Complétons tout d’abord le code du constructeur



N.B : le code ci-dessus suppose que le fichier bmp et la classe portent le même nom. Codons ensuite la fonctionnalité à proprement parle r. Nous allons utiliser des snippets ArcGIS, i.e. des morceaux de code directement réut ilisables. Placer le curseur sur la ligne précédent la fin de classe et insérer par clic droit l’extrait de code ArcGIS bureautique>Mapping>Zoom to active Layer in TOC.

L’extrait peut à tout moment être réduit en cliquan t sur le signe « - » dans la marge gauche.



La procédure ainsi ajoutée permet de modifier l’éte ndue de la fenêtre cartographique. Cette procédure a un paramètre : un e référence vers le document ArcMap ouvert. Pour obtenir une référence vers le document, nous a llons utiliser un deuxième extrait de code : ArcGIS bureautique>mapping>Map documents>Get MxDocu ment from ArcMap . Ce code permet d’obtenir la référence vers le docum ent à partir de l’application, laquelle est accessible par la propriété membre de notre classe. Il s’agit maintenant d’appeler les procédures ci-de ssus dans la méthode OnClick qui sera appelée en réaction au clic utilisateur sur no tre commande lorsque celle-ci aura été intégrée à l’interface d’ArcMap. Compléter le code comme suit :

Voilà, c’est presque fini. Il reste à faire en sort e que notre classe soit reconnue comme une classe COM (on rappelle que tous les comp osants ArcGIS sont des composants COM), ce qui n’est pas le cas par défaut lorsqu’on développe un composant en environnement .Net. La compatibilité « COM » a en fait déjà été prise e n charge par l’assistant lors de la création de la classe. Il s’agit des procédures stockées dans la zone COM registration functions . Il n’y a plus qu’à compiler notre classe. Enregistr er d’abord le projet puis compiler avec le menu Générer>Générer nom du projet . Le résultat de la compilation et de l’édition de li ens est un composant DLL stocké dans le sous-dossier bin>Release.



On peut maintenant intégrer la commande à l’IHM d’A rcMap. A l’aide du menu Personnaliser aller chercher dans la catégorie Developer Samples (c’est bien ainsi que nous avons rempli la propriété category dans le constructeur de la classe) la commande que nous venons de créer.

On peut également créer un composant exécutable en mode debug et l’intégrer à l’interface d’ArcMap.



Il faut tout d’abord définir ArcMap comme application de déboguage. Pour ce faire ouvrir les propriétés (volet Déboguer) du projet da ns l’explorateur.

Ajouter ensuite un point d’arrêt sur une instructio n exécutable (au niveau du constructeur de la classe par exemple) et exécuter depuis Visual Studio : Arcmap est exécuté ; si o ouvre un document qui contient u ne référence vers la commande, alors celle-ci va être exécuté en mode debug.



Annexe 4 : retour sur la programmation d’évènements avec l’API ArcObjects.

Certains ArcObjects sont capables de répondre à des évènements. On retrouve ici une caractéristique des logiciels pilotés par des IHM : les calculs sont le plus souvent déclenchés consécutivement à des actions ut ilisateurs sur les éléments de l’interface.

On le sait, COM impose de manipuler les ArcObjects à travers des interfaces. Telles qu’on les a présentées jusqu’à présent, les interfa ces donnent accès à des propriétés et des traitements clairement explicités . Les évènements ne rentrent pas dans ce cadre là puisque c’est le client qui décide de la façon dont les évènements sont traités (ce qui doit se passer par exemple lor sque la sélection courante d’entités change ; ou bien quand l’on numérise de n ouvelles entités).

COM propose en fait deux types d’interface : les inbound interfaces et les outbound interfaces.

• Les inbound interfaces sont les plus courantes : elles permette nt au client de faire appel à des fonction implémentées par l’ob jet. Elles sont figurées par une sucette évidée.

• Les outbound interfaces permettent de gérer les évènements. Le mécanisme est différent : c’est l’objet qui fait appel au client lequel prend en charge l’évènement. Elles sont figurées par une sucette pleine.

Dans l’extrait de diagramme ci-après (Géodatabase), on constate que la classe ObjectClass implémente les deux types d’interfaces et en partic ulier l’interface IObjectClassEvents laquelle permet de traiter les évènements de créat ion , modification et destruction relatifs à tous les typ es d’entités.



En guise d’exemple, si l’on souhaite prendre en cha rge (ou écouter) les évènements de l’interface ObjectClassEvents pour une classe d’entités chargée dans le document ArcMap courant, on déclare en VBA un pointeur globa l avec le mot clé WithEvents comme suit 'la variable globale pObjEvent est un écouteur pour l’interface 'd’évènements de la classe ObjectClassEvents

Private WithEvents pObjEvent as ObjectClassEvents

puis on instancie l’écouteur avec l’objet que l’on souhaite voir réagir aux évènements Public Sub initEvents()

Dim pMxdoc As IMxDocument Set pMxdoc = Application.Document Dim pFeatureLayer As IFeatureLayer Dim pLayer As ILayer Dim pFeatureClass As IFeatureClass Set pLayer = pMxdoc.FocusMap.Layer(0) Set pFeatureLayer = pLayer Set pFeatureClass = pFeatureLayer.FeatureClass Dim pObjectClass As IObjectClass Set pObjectClass = pFeatureClass Set pObjEvent = pObjectClass

End Sub

puis on implémente dans le même module les évènemen ts que l’on souhaite gérer.

Private Sub pObjEvent_OnChange(ByVal obj As IObject ) MsgBox "OnChange for: " & obj.OID

End Sub

Private Sub pObjEvent _OnCreate(ByVal obj As IObject) MsgBox "OnCreate fo r: " & obj.OID End Sub Private Sub pObjEvent _OnDelete(ByVal obj As IObject) MsgBox "OnDelete fo r: " & obj.OID End Sub

Pour que le client “écoute” les évènements change, create et delete ainsi décrits il faut bien entendu exécuter la procédure initEventsI (on peut par exemple l’appeler à l’ouverture du document). Même si ces outbound interfaces ne sont pas les plu s nombreuses, on les retrouve néanmoins sur un certain nombre de classes ArcObjec ts. Pour s’en persuader un deuxième exemple :



le diagramme ci-dessus est extrait de l’OMD Editor qui décrit l’environnement de mise à jour des données dans ArcMap. Cette classe permet de paramétrer l’environnement i nteractif de mise à jour (classe d’entités cible, type d’opération, options de snap, ....) mais aussi de gérer un certain nombre d’évènements. L’interface IEditEvents permet entre autre de répondre à la création d’une entité, à sa destruction, aux annulations, au changement d’outil, ...

'la variable globale pEditorEvent est un écouteur p our l’interface 'd’évènements par défaut de la classe Editor Private WithEvents pEditorEvent As Editor ' on instancie le pointeur de façon à ce qu’il écou te les évènements ' générés par l’objet Editeur du document ArcMap co urant Public Sub InitEvents() 'la classe ArcObject Editor est une classe simpl e; pour obtenir un 'pointeur sur un objet de cette classe il faut d onc passer 'un autre objet : ici par l’objet Application Dim pUID As New UID pUID = "esriEditor.Editor" Set pEditorEvent = Application.FindExtensionByCL SID(pUID) If pEditorEvent Is Nothing Then Exit Sub MsgBox "pEditorEvent a été instancié" End Sub Private Sub pEditorEvent_OnStartEditing() MsgBox "On a ouvert une session d’édition" End Sub Private Sub pEditorEvent_OnStopEditing(ByVal save A s Boolean) MsgBox "On a fermé une session d’édition" End Sub Private Sub pEditorEvent_OnCreateFeature(ByVal obj As esriGeoDatabase.IObject) MsgBox "On a créé une nouvelle entité" End Sub Private Sub pEditorEvent_OnDeleteFeature(ByVal obj As esriGeoDatabase.IObject) MsgBox "On a détruit une entité"



End Sub Private Sub pEditorEvent_OnSelectionChanged() MsgBox "la sélection a changé" End Sub Private Sub pEditorEvent_OnUndo() MsgBox "une opération vient d’être annulée" End Sub



Annexe 5 : Création d’une application web avec visual studio 2005 à partir du template d’application livré avec ArcGIS Server Prérequis : un map service ArcGIS Server doit avoir été créé a u préalable. Démarrer Visual Studio 2005 et créer un nouveau pro jet de type Site web . Sélectionner C# comme langage puis Web mapping template parmi les templates proposés. La page Default.aspx contient tous les controls de l’application web ainsi que les évènements tels qu’ils sont implémentés en standard .

Passer en mode design.



On peut voir les différents composants de l’interfa ce du template d’application web (le pavé Résultats en haut à gauche, le pavé table des matières en dessous, le pavé Carte à leur droite ainsi que les managers qui sont des objets permettant de paramétrer le contenu des éléments d’interface. Sélectionner le map resource manager et clicker sur la flèche pour accéder au menu contextuel. Editer les propriétés.



Ajouter une nouvelle ressource et la paramétrer de façon à utiliser un map service géré par le serveur ArcGIS Server local (ou distant si on ne développe sur la machine serveur).



Compiler puis exécuter le projet.



Annexe 6 : démarrer avec l’API Javascript Préambule : tous les exemples sont tirés du centre de ressou rces Esri

Partie 1 : inclure une carte dans une page web

Code : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Create a Map</title> <meta http-equiv="Content-Type" content="text/h tml; charset=utf-8"/> <link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgi s/1.4/js/dojo/dijit/themes/tundra/tundra.css"> <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis /?v=1.4"></script> <script type="text/javascript"> dojo.require("esri.map"); var myMap, myTiledMapServiceLayer; function init() { myMap = new esri.Map("mapDiv"); myTiledMapServiceLayer = new esri.layers.ArcGISTiledMapServiceLayer ("http://server.arcgisonline.com/ArcGIS/rest/servic es/ESRI_StreetMap_World_2D/MapServer"); myMap.addLayer(myTiledMapServiceLayer); } dojo.addOnLoad(init); </script> </head> <body> <div id="mapDiv" class="tundra" style="width:90 0px; height:600px; border:1px solid #000;"></div> <h4>Work flow:</h4> <ul> <li>Create a map.</li> <li>Add an ArcGISTiledMapServiceLayer.</li> </ul> </body> </html>

Commentaires : La partie head de la page web doit comporter deux scripts : un qui référence l’API en ligne http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1 .4 (à la date de rédaction de ce document la version courante est la 1.4) et un autre qui contient le code permettant d’interagir avec la carte. Dans l’exemple ci-dessus, le script instancie un co mposant Map puis un composant layer (pour être exact, un composant de type ArcGISTiledMapServiceLayer , autrement dit un flux d’images dallées servies par un serveur ArcGIS) et ajoute la couche à la carte. De manière plus détaillée, le script est structuré en trois parties :

• Chargement des bibliothèques utiles de l’API : ici, on importe uniquement esri.map . Pour ce faire on utilise l’objet dojo . L’instruction dojo.require est l’équivalent d’un import ou include dans d’autres langages.

• Une fonction init (et éventuellement toutes les autres fonctions que celle-ci peut appeler) contenant les instructions de créa tion de la carte interactive.

• La réponse à l’évènement de chargement de la page w eb dans le navigateur. Ici, la réponse à l’évènement est prise en charge p ar l’objet dojo à travers la méthode AddOnLoad() . C’est le code de la fonction init() qui est exécuté au chargement de la page.

La partie body de la page web est ici très simple puisqu’elle ne comporte qu’une seule div (ou section), nommée mapDiv , contenant le composant Map instancié au chargement, ainsi qu’un paragraphe de texte.



Partie 2 : programmer un évènement L’utilisation de l’API Javascript ne se conçoit que dans le cadre d’une application interactive, réagissant de manière personnalisée au x différentes actions de l’utilisateur. La programmation est donc essentiell ement à base d’évènements. Parmi les évènements gérés, il y a ceux qui sont tr aités immédiatement et ceux qui sont traités en mode asynchrone après un aller-reto ur avec le serveur (principe AJAX). Quel que soit l’évènement, afin de le prendre en ch arge, il faut ajouter du code qui « écoute », à savoir du code qui permet de décl encher l’exécution d’un traitement lorsque l’évènement survient. Dans l’API Javascript, c’est la méthode dojo.connect qui permet de définir des écouteurs d’évènements. Il faut fournir à cette mét hode trois paramètres :

• L’objet en lien avec l’évènement • L’évènement • La fonction qui prend en charge l’évènement (le handler )

En guise d’exemple, l’appel suivant permet de défin ir un écouteur pour l’évènement clic sur l’objet map ainsi que le nom de la fonction traitant l’évèneme nt. var monclicconnect = dojo.connect(map, « onClick », monClicHandler) Il faut désallouer les écouteurs lorsqu’on quitte l ’application afin d’éviter les fuites mémoire. Pour ce faire, on crée un écouteur pour l’évènement onUnload et on déconnecte les différents écouteurs alloués dans le handler de ce onUnload à l’aide de la méthode Disconnect . var monunloadconnect = dojo.connect(map, « onUnload »,monUnloadHandler) function monUnloadHandler(event) { dojo.disconnect(monclicconnect); }

Code : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Create a Map</title> <meta http-equiv="Content-Type" content="text/h tml; charset=utf-8"/> <link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgi s/1.4/js/dojo/dijit/themes/tundra/tundra.css"> <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis /?v=1.4"></script> <script type="text/javascript"> dojo.require("esri.map"); var myMap, myTiledMapServiceLayer; function init() { myMap = new esri.Map("mapDiv"); dojo.connect(myMap,"onClick",monClicHandler); dojo.connect(myMap,"onUnload",monOnUnloadHandler) ; myTiledMapServiceLayer = new esri.layers.ArcGISTiledMapServiceLayer("http://serv er.arcgisonline.com/ArcGIS/rest/services/ESRI_StreetMap_World_2D/MapServer"); myMap.addLayer(myTiledMapServiceLayer); } function monClicHandler(event) { alert("L'utilisateur a cliqué en " + event.mapPoi nt.x + "," + event.mapPoint.y); } function monOnUnloadHandler(event) { dojo.disconnect(monClicHandler); } dojo.addOnLoad(init); </script> </head>



<body> <div id="mapDiv" class="tundra" style="width:90 0px; height:600px; border:1px solid #000;"></div> </body> </html>

Commentaires : Le code précédent affiche les coordonnées lorsqu’on clique sur le fond de carte StreetMap servi par ArcGISOnline.

Partie 3 : ajouter des données servies dynamiquemen t en WMS Le code suivant étend les possibilités entrevues da ns le premier extrait de code. Il montre comment paramétrer l’extension spatiale d e la vue cartographique (alors que le code précédent affiche toute l’étendue spati ale de la couche de base). Il permet surtout de superposer à une couche de base s ervie par un serveur ArcGIS Serveur une couche gérée par un serveur WMS. En effet, même si par défaut, l’API Javascript ne p ermet d’afficher que des données servies par des serveurs ArcGIS selon les protocole s définis par Esri, il est possible à l’aide du Dojo d’étendre les deux classes de couches prédéfinies que sont DynamicMapServiceLayer et TiledMapServiceLayer .

Code : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/h tml; charset=utf-8"> <meta http-equiv="X-UA-Compatible" content="IE= 7" /> <title>WMS</title> <link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgi s/1.4/js/dojo/dijit/themes/soria/soria.css"> <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis /?v=1.4"></script> <script type="text/javascript"> dojo.require("esri.map"); dojo.declare("pgwWMSLayer", esri.layers.DynamicM apServiceLayer, { constructor: function() { this.initialExtent = this.fullExtent = ne w esri.geometry.Extent({xmin:-180,ymin:-90,xmax:180,ymax:90,spatialReference:{wkid:4326}}); this.spatialReference = new esri.SpatialR eference({wkid:4326}); this.loaded = true; this.onLoad(this); }, getImageUrl: function(extent, width, height , callback) { var params = { request:"GetMap", transparent:"true", format:"image/png", bgcolor:"ffffff", version:"1.1.1", layers:"gpw2005", styles: "default", exceptions: "application/vnd.ogc.se_xml ", //changing values bbox:extent.xmin + "," + extent.ymin + "," + extent.xmax + "," + extent.ymax, srs: "EPSG:" + extent.spatialReference. wkid, width: width, height: height }; callback("http://iceds.ge.ucl.ac.uk/cgi-b in/icedswms?"+dojo.objectToQuery(params)); } }) dojo.declare("brgmWMSLayer", esri.layers.Dyna micMapServiceLayer, { constructor: function() { this.initialExtent = this.fullExtent = ne w esri.geometry.Extent({xmin:-10,ymin:40,xmax:15,ymax:52,spatialReference:{wkid:4 326}}); this.spatialReference = new esri.SpatialR eference({wkid:4326}); this.loaded = true;



this.onLoad(this); }, getImageUrl: function(extent, width, height , callback) { var params = { request:"GetMap", transparent:true, format:"image/png", bgcolor:"ffffff", version:"1.1.1", layers:"departments,communities", styles: "default,default", exceptions: "application/vnd.ogc.se_xml ", //changing values bbox:extent.xmin + "," + extent.ymin + "," + extent.xmax + "," + extent.ymax, srs: "EPSG:" + extent.spatialReference. wkid, width: width, height: height }; callback("http://swing.brgm.fr/cgi-bin/li mitesadm?" + dojo.objectToQuery(params)); } }) --> function init() { var map = new esri.Map("map"); var startExtent = new esri.geometry.Extent(-6.0625 80, 41.163200, 10.878300, 51.291800,new esri.SpatialReference({wkid:4326}) ); map.setExtent(startExtent); map.addLayer(new esri.layers.ArcGISTiledMapServiceLayer("http://serv er.arcgisonline.com/ArcGIS/rest/services/ESRI_Imagery_World_2D/MapServer")); var pgwLayer = new pgwWMSLayer(); pgwLayer.setOpacity(.75); map.addLayer(pgwLayer); map.addLayer(new brgmWMSLayer()); } dojo.addOnLoad(init); </script> </head> <body> <div id="map" class="soria" style="position:rel ative; width:1024px; height:512px; border:2px solid #000;"></div> </body> </html>

Commentaires : Dans le code précédent, on crée une carte avec troi s sources de données dynamiques :

• Les données mondiales image 2D du serveur arcgisonl ine • La carte de densité de population en 2005 du serveu r WMS

http://iceds.ge.ucl.ac.uk/cgi-bin/icedswms ? • La carte des limites administratives départementale s et communales du serveur

WMS http://swing.brgm.fr/cgi-bin/limitesadm ? Pour prendre en charge les couches WMS, on crée deu x nouvelles classes de couches ( custom layers ) héritant de la classe prédéfinie DynamicmapServiceLayer à l’aide de dojo.declare() . La méthode declare a 4 paramètres :

• Le nom de la nouvelle classe de couche • Le nom de la classe dont elle hérite • La fonction qui implémente le constructeur de la no uvelle classe, laquelle

détermine l’étendue spatiale initiale et totale des données ainsi que le système de référence

• La fonction qui implémente la méthode getImageUrl, qui détermine les paramètres (dimensions, transparence, format, liste des couches) de l’image que le serveur doit retourner.

Ces deux classes étant déclarées, le code de créati on de la carte interactive est très proche de celui du premier exemple : en effet, le code instancie un objet esri.map , puis un objet esri.geometry.Extent pour définir l ’étendue de la carte



lors de l’affichage initial. Il ajoute ensuite la c ouche arcgisonline, puis chacune des deux couches servies en WMS.

Partie 4 : ajouter des données en cache sur un serveur (ex: les données OpenStreetMap). Utiliser l es widgets du Dojo.

Code : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Afficher des données OpenStreetMap</titl e> <meta http-equiv="Content-Type" content="text/h tml; charset=utf-8"/> <link rel="stylesheet" type="text/css" href="http://serverapi.arcgisonline.com/jsapi/arcgi s/1.4/js/dojo/dijit/themes/tundra/tundra.css"> <script type="text/javascript" src="http://serverapi.arcgisonline.com/jsapi/arcgis /?v=1.4"></script> <script type="text/javascript"> var djConfig = { parseOnLoad: true } </script> <script type="text/javascript"> dojo.require("esri.map"); dojo.require("dijit.form.Slider"); var map, layer1, layer2; //pour en savoir plus http://resources.esri.com/help/9.3/arcgisserver/api s/javascript/arcgis/help/jshelp/inside_custom_layers.htm dojo.declare("OpenStreetMapLayer", esri.laye rs.TiledMapServiceLayer, { //constructeur de la nouvelle couche constructor: function() { this.spatialReference = new esri.Spat ialReference({ "wkid": 102113 }); //paramètres des dalles aux différentes é chelles this.tileInfo = new esri.layers.TileInfo( { "rows": 256, "cols": 256, "dpi": 96,

"format": "PNG8", "compressionQuality": 0, "origin": { "x": -20037508.342787, "y": 20037508.342787 }, "spatialReference": { "wkid": 102113 }, "lods": [{ "level": 0, "scale": 591657527.5915 55, "resolution": 156543.03 3928 }, { "level": 1, "scale": 295828763.7957 77, "resolution": 78271.516 9639999 }, { "level": 2, "scale": 147914381.8978 89, "resolution": 39135.758 4820001 }, { "level": 3, "scale": 73957190.94894 4, "resolution": 19567.879 2409999 }, { "level": 4, "scale": 36978595.47447 2, "resolution": 9783.9396 2049996 }, { "level": 5, "scale": 18489297.73723 6, "resolution": 4891.9698 1024998 }, {



"level": 6, "scale": 9244648.868618 , "resolution": 2445.9849 0512499 }, { "level": 7, "scale": 4622324.434309 , "resolution": 1222.9924 5256249 }, { "level": 8, "scale": 2311162.217155 , "resolution": 611.49622 628138 }, { "level": 9, "scale": 1155581.108577 , "resolution": 305.74811 3140558 }, { "level": 10, "scale": 577790.554289, "resolution": 152.87405 6570411 }, { "level": 11, "scale": 288895.277144, "resolution": 76.437028 2850732 }, { "level": 12, "scale": 144447.638572, "resolution": 38.218514 1425366 }, { "level": 13, "scale": 72223.819286, "resolution": 19.109257 0712683 }, { "level": 14, "scale": 36111.909643, "resolution": 9.5546285 3563415 }, { "level": 15, "scale": 18055.954822, "resolution": 4.7773142 6794937 }, { "level": 16, "scale": 9027.977411, "resolution": 2.3886571 3397468 }] }); //étendue spatiale totale de la couc he. this.fullExtent = new esri.geom etry.Extent({ "xmin": -20037508.34, "ymin": -20037508.34, "xmax": 20037508.34, "ymax": 20037508.34, "spatialReference": { "wkid": 102113 } }); //étendue spatiale initiale de la couche this.initialExtent = new esri.g eometry.Extent({ "xmin": -35222182.633799955 , "ymin": -19567879.240999974 , "xmax": 35222182.633799955, "ymax": 19567879.240999974, "spatialReference": { "wkid": 102113 } }); //url des serveurs de tuiles op enStreetMap this.servers = ["http://a.tile. openstreetmap.org/", "http://b.tile.openstreetmap.org/", "http://c.tile. openstreetmap.org/"]; this.serversLength = this.serve rs.length; this.serverIndex = 0; this.loaded = true; this.onLoad(this); }, getTileUrl: function(level, row, co l) { //retourne la dalle en cache su r le serveur correspondant aux numéros de ligne et colonne indiqués return this.servers[this.server Index++ % this.serversLength] + level + "/" + col + "/" + row + ".png"; } }); function init() {



La barre de réglage du niveau de transparence est g érée sous forme d’un dijit , composant d’interface pré-programmé (un des avantag es du toolkit dojo ) qui, en réponse à l’évènement onChange , met à jour la div affichant le niveau de transparence.

Partie 5 : faire afficher les résultats d’une requê te vers un serveur ArcGIS Serveur sur un fond Google Maps Cet exemple montre comment utiliser l’extension Arc GIS pour l’API Google Maps afin d’exploiter les résultats d’une interaction avec un serveur ArcGIS sur un fonds Google Maps.

Code : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " http://www.w3.org/TR/html4/strict.dtd"> <html debug=true> <head> <meta http-equiv="Content-Type" content="text/h tml; charset=iso-8859-1" /> <title>Query Task (Returns Point)</title> <script src="http://maps.google.com/maps?file=api&v=2&a mp;key=DioG219lPJG3WTn3zmQqebsjVg" type="text/javascript"></script> <script src="http://serverapi.arcgisonline.com/ jsapi/gmaps/?v=1.4" type="text/javascript" ></script> <script type="text/javascript"> var gmap = null; var qtask = null; var query = null; var mapExtension = null; var gOverlays = null; function initialize() { // création du fond Google Maps gmap = new GMap2(document.getElementById('g map')); gmap.addMapType(G_NORMAL_MAP); gmap.addMapType(G_SATELLITE_MAP); gmap.addControl(new GLargeMapControl()); gmap.addControl(new GMapTypeControl()); gmap.setCenter(new GLatLng(33.9696480651975 1, -117.37674951553345), 17); // RIVERSIDE (Point) gmap.enableScrollWheelZoom(); //instanciation du mapExtension mapExtension = new esri.arcgis.gmaps.MapExt ension(gmap); // instanciation du Query Task qtask = new esri.arcgis.gmaps.QueryTask("http://sampleserver1.a rcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Census_USA/MapServer/0"); // instanciation de la requête query = new esri.arcgis.gmaps.Query(); } function executeQuery() { var bounds = gmap.getBounds(); // on efface les markers et les écouteurs d 'évènements associés mapExtension.removeFromMap(gOverlays); // paramétrage de la requête query.queryGeometry = bounds; query.returnGeometry = true; // exécution de la requête sur le service A rcGIS Server instancié qtask.execute(query, false, mycallback); } function mycallback(fset) { var myMarkerOptions = { title: "2000 Population: {POP2000}" }

Cours Arcgis Developpement

Documents

Transcript of Cours Arcgis Developpement