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 Framework) ........................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 ArcObjects en environnement VB. .44
III.4.3. Pratique des concepts de classe et d’interface .......................47
ANNEXES ..................................... 50
Annexe 1 : personnalisation Arcgis bureautique en VBA...........................50
Annexe 2 : extension ArcGIS bureautique avec Microsoft Visual Basic 6...........53
Annexe 3 : extension ArcGIS bureautique avec Microsoft .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 visual 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 dynamiquement en WMS ...................76
Code : ......................................................................76
Commentaires : ..............................................................78
Partie 4 : ajouter des données en cache sur un serveur (ex: les données
OpenStreetMap). Utiliser les widgets du Dojo. .................................78
Code : ......................................................................78
Commentaires : ..............................................................81
Juillet 2010 – v3.1
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
Alexandre Pauthonnier 3/82

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 gain de productivité important. En
effet, un utilisateur de SIG est amené dans l’exercice de son métier à reproduire
un grand nombre de fois des opérations ou des traitements semblables. S’il dispose
d’outils qui automatisent tout ou partie de ces traitements, c’est un gain de temps
considérable.
Par ailleurs, l’évolution récente du monde de l’information 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éation 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 tout cela est du ressort du
développeur.
Face à ces enjeux, les produits ArcGIS apportent des solutions complètes et de
grande qualité.
On observe tout d’abord que la gamme couvre tous les 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 pris 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 « ouverts » : 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.NET, Java, Python) et les
environnements de développement (Microsoft Visual Studio, 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 principes de l’orienté-objet et
qui assure une réutilisabilité maximale de ces composants. Ces derniers sont
accessibles aux développeurs à travers une API : les ArcObjects. Cette API
s’adresse essentiellement aux développeurs de fonctions 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 aide 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 logicielles SIG. Les différents
produits permettent d’exploiter les données géographiques dans un contexte
bureautique, à travers un réseau intranet ou internet 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 (donné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 Desktop) : une suite composée
d’ArcMap, ArcCatalog, ArcGlobe et ArcScene. Ces applications permettent de
• Gérer les données géographiques, i.e. créer et administrer des bases de
données (ou bien des sources de type fichier) contenant 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 divers 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 produit clé en main, qui peut
toutefois être complètement adapté aux besoins de l’utilisateur.
On trouve également dans cette famille d’applications 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'applications 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 application que l’on peut
télécharger gratuitement qui permet de visualiser les 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 (locales, services web), utiliser
quelques outils simples d’analyse spatiale (recherche 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, ArcGIS 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 membres d’une même organisation, ou

de plusieurs organisations, voire à un public aussi large que possible des
ressources de nature géographique. Ces services peuvent être des cartes, de la
donnée brute, des traitements sur les données.
Cette technologie s’appuie sur le modèle de communication client-serveur utilisant

les protocoles HTTP et TCP/IP et est bâtie en cohérence avec les normes et standard
développés par le W3C (World Wide Web consortium) et l’OGC (Open GIS Consortium).
Elle est ainsi conçue pour s’intégrer au SI de l’entreprise : 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 relation 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 : les
cartes, les globes, les modèles d’analyse et de géotraitement.
Les produits serveur permettent enfin de déployer des outils qui répondent
précisément au besoin et au profil de leurs utilisateurs. L’accès aux services
hébergés sur le serveur (données, cartes, traitements) se fait le plus souvent à
travers des clients web légers dont l’interface épuré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 Serveur et ArcIMS qui ne s’inscrivent

pas dans la même dynamique. ArcGIS Serveur est la technologie 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 publier de la cartographie dynamique

(webmapping) ainsi que des catalogues de métadonnées. L’outil est fourni avec un
assistant de création de site web. Toutefois la mise 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’interface 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, technologie 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 un ensemble d’outils et de
technologies web permettant le partage de ressources SIG sur un réseau. L’idée est
de donner accès à travers un navigateur aux mêmes fonctionnalité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’information géographique et notamment à
des fins d’analyse et d’aide à la décision. Un usage 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 ArcGIS Server s’inscrit dans une
architecture client-serveur reposant sur le protocole de communication HTTP. La
partie serveur est constituée de programmes et de donné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 rendre 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 client. Toutefois, selon la
philosophie d’une telle architecture, c’est le serveur 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 cartographiques, globes 3D)
• des géo-traitements ou fonctions permettant d’interagir 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 à partir 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, ArcGlobe, Modelbuilder et Python pour
les processus de géo-traitement).
Lorsque les données spatiales sont archivées dans une 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 à fait possible d’archiver les
données géographiques dans des formats fichiers ou géodatabase personnelle.
Afin de rendre les ressources partageables, le serveur expose les ressources sous
forme de services. Un service peut être vu comme la représentation normalisée d’une
ressource, rendue de ce fait consommable par des clients 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 identifiant et mot de passe) voire étendu
à tout l’internet. C’est le deuxième rôle joué par le serveur SIG : publier 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 pourvu que celles-ci soient
connectées par le réseau. La logique de service implique également la
normalisation des accès à la fonctionnalité : l’objectif est de permettre à
différents types de clients, lourds, riches, légers, mobiles de consommer le
service ; cela passe par l’utilisation de protocoles 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-traitement (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 faut
ensuite le stocker dans un répertoire accessible par ArcGIS Server et s’assurer que
les données géographiques qu’il contient sont également 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 directement. 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 qui 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 coûteux en temps d’exécution, on

privilégiera donc la deuxième solution. Il est possible 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ées, 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 une méthode
de géocodage (ex : géocodage à l’adresse postale) par rapport à un référentiel
(ex : la BD Adresse® de l’IGN).
Les geodata service permettent d’interagir avec les données d’une geodatabase par
le biais d’ArcGIS Server. Ils permettent l’exploitation (requêtes) et
l’administration (extraction, réplication, …) de donné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 les tables que l’on souhaite
publier et on publie le document.
Les geometry service sont pour certains géotraitements simples une alternative aux
geoprocessing service. Ils permettent de réaliser des calculs relatifs à la
géométrie d’une ou plusieurs entités : buffer, simplification 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émarrage, 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 possible de concevoir une
architecture dans laquelle les clients qui consomment les services d’ArcGIS Server
sont des clients bureautiques ESRI (ArcMap, ArcGlobe …), 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 de geoprocessing services. Dans
ce cas précis, la communication se fait selon un protocole binaire propriétaire.
Toutefois, rappelons que les ambitions d’un SIG serveur 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 SIG, et notamment de donner
l’accès à la donnée à quiconque peut en avoir l’usage quel que soit les outils
qu’il possède.
ArcGIS Server a été conçu pour répondre à ces besoins. Par défaut les services
créés sont accessibles selon deux protocoles : le protocole binaire évoqué plus
haut et SOAP. SOAP est un protocole standardisé dans 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 offrent des objets capables de
générer et parser des messages SOAP/XML. Il est donc possible de développer côté
serveur une application consommant des services ArcGIS 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 localisation 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’envoyer une requête HTTP ; c’est
possible avec un client Javascript AJAX. On peut donc développer côté client.

N.B : si vous souhaitez approfondir ces notions, vous 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 publication des services selon les

normes OGC. Ces normes (WMS, WFS, WCS) permettent respectivement de publier les
couches d’une carte sous forme d’une image, les données spatiales sous forme de
vecteur ou de raster et ce dans une sorte d’esperanto, reconnu directement par tous
les SIG, propriétaires ou Open Source. Contrairement à 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 pas automatique : il faut
l’indiquer explicitement au moment de la publication.
En résumé, les services publiés par ArcGIS Server sont 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 server>/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 server>/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 monserveur
les urls suivantes

• interopérabilité ArcGIS :
http://monserveur/arcgis/services/test_arcpad/MapServer
• interopérabilité WMS :
http://monserveur/arcgis/services/test_arcpad/MapServer/WMSServer
• interopérabilité KML :
http://monserveur/arcgis/services/test_arcpad/MapServer/KmlServer
• interopérabilité WFS :
http://monserveur/arcgis/services/test_arcpad/MapServer/WFSServer
• interopérabilité WCS :
http://monserveur /arcgis/services/test_arcpad/MapServer/WCSServer
Ces url ne peuvent pas être requêtées directement par un navigateur. 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 fichiers xml. Ce sont des requêtes
SOAP.
Pour accéder en REST aux services, on utilise le service 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/services) :

Les services sont ici organisés dans une arborescence de dossiers. Un système
d’hyperliens permet d’accéder à la description de chaque 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 correcte 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 straté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 service 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 (autant 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 le 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 pré-calculer un cache pour les

données cartographiques de type image. Selon l’étendue 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 automatique 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 évidemment 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 consiste à 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 OpenLayers
• 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 Server passe souvent par le
développement d’un client personnalisé.
Le Manager propose une interface pour créer très simplement un 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 traitements 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 fonctionnalités métier, il convient de les
développer et des intégrer à l’IHM. Il y a alors plusieurs 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évelopper côté client à l’aide des
API Javascript, Flex ou Silverlight.
ArcGIS Server est commercialisé en 3 niveaux de licence : Basique, Standard et

Advanced. Le tableau suivant récapitule les différentes 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éographique 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écessaire de disposer du niveau

« advanced » pour mettre à jour les données du serveur à l’aide d’une application
web ou mobile. Il faut également savoir que l’édition 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 (carte, 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 consiste en un ensemble d’outils

permettant le stockage de ressources, l’administration de ces ressources et leur
déploiement à travers des applications webs.
La mise en œuvre d’ArcGIS Server s’inscrit donc dans 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 application cliente.

faisant intervenir des publics différents : créateurs et administrateurs de

ressources, développeurs webs, utilisateurs in fine
On retiendra également que les avantages d’une solution SIG serveur sur une
solution bureautique tiennent essentiellement aux points 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/arcgisserver/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éveloppement d’applications de
webmapping avec ArcGIS Server.
I.3. Les applications mobiles

Ces outils sont destinés aux équipes de terrain, qui dans le cadre de leur activité
sont amenées à créer, mettre à jour, afficher et éventuellement 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 logiciel clé en main et ArcGIS Mobile
un kit de développement permettant de développer des applications nomades
centralisées et synchronisées avec un serveur ArcGIS Server.
Il est possible d’interfacer ArcPad avec une solution ArcGIS Server, permettant
ainsi aux équipes de terrain de travailler en direct 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 service 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. La mise à jour de données par des
équipes de terrain suppose également un accès concurrentiel à 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 contenu (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 principal ailleurs. On trouve aussi la
couverture mondiale SRTM à 90m de résolution.
Les services ArcGIS online sont diffusés avec la technologie 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’une 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’autres 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 selon 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 possibilités de développement.
Toutes les applications ArcGIS sont conçues à partir des mêmes composants : les
ArcObjects, lesquels portent les fonctionnalités SIG. Lorsqu’on développe autour
d’un produit ArcGIS on est donc amené a priori à manipuler ces classes d’objets que
sont les ArcObjects. Il s’agit donc de programmation 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 cas, 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 second 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’identification développé pour un
client web agit donc sur des ArcObjects distants.
L’API ArcObjects n’est toutefois pas la seule API ouverte au développement. Il faut
la considérer comme l’API de référence, celle qui donne 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’emploi, 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 redé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 (Visual Basic pour Application) :
le travail consiste alors à développer des macros en Visual Basic dans
l’environnement de programmation intégré à ArcMap, ArcSCene, ArcGlobe.
N.B : Cette possibilité de développement intégré existe à l’identique dans les

applications de la suite Office (Word, Excel, Access, …), 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 outils à l’aide des environnements

de programmation standard Windows : Microsoft Visual 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éveloppement d’outils de géotraitement à

l’aide de Modelbuilder et d’environnement de programmation de scripts. Ce sont des
environnements de développements intégrés à ArcToolbox, l’IHM de géotraitement
d’ArcGIS. Le développeur y accède à travers un ArcObject particulier : le
géoprocesseur.
II.1.1.1. Personnalisation avec VBA

Le débutant doit commencer par là car c’est le moyen le plus rapide de réorganiser
l’interface et de coder de nouvelles fonctionnalités.

Sans écrire une seule ligne de code, il est possible de

• Réorganiser les barres d’outils et les commandes qu’elles contiennent
• Ajouter de nouveaux outils déjà programmés sous forme 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 ArcMap, ArcCatalog et ArcScene de
VBA (Visual Basic pour Applications), un environnement de programmation intégré qui
permet de développer sous forme de macros de nouvelles fonctionnalités. Le langage
de développement est le Visual Basic (VB).
Plusieurs choses assurent une prise en main relativement aisée :

• les bibliothèques ArcObjects sont chargées en mémoire ; certains objets (le
document, l’application) sont accessibles à travers des variables globales
prédéfinies.
• la possibilité de créer sans programmer de nouvelles commandes (boutons ou
outils) et d’y attacher sous forme de code évènementiel la nouvelle
fonctionnalité
• la possibilité de définir des IHM élaborées (à l’aide des objets formulaires)
et notamment d’y intégrer tout type de composants (ActiveX)
• la prise en charge par la machine virtuelle VB de toute une partie du code
(désallocation mémoire)
• un environnement de débogage
Pour sa simplicité de mise en œuvre c’est la configuration retenue à l’ENSG : elle

permet aux étudiants de manipuler les ArcObjects dans 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écution : cela signifie donc que ce
mode n’est pas adapté à la programmation de traitements lourds. Par ailleurs ce
mode intégré comporte certaines restrictions : on ne peut pas créer d’extensions de
classe, ni de nouveaux modes de représentation cartographique. Enfin, le code
source est difficilement protégeable. Si l’on ne souhaite pas diffuser son code, la
seule solution c’est de le compiler avec un IDE standard et de l’intégrer sous
forme d’un composant binaire (DLL, exe, ocx) à l’IHM d’ArcGIS bureautique.
Le site resources.esri.com regroupe toutes les informations 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’apprentissage 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 sources, classés par thématiques
(accès à une base de données, mise à jour de données, calculs 3D, calculs réseau)
sont fournis.

L’annexe 1 propose une introduction brève au développement 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’utiliser des IDE non intégrés tels
Microsoft VB ou Microsoft Visual Studio qui vont permettre au développeur
• de travailler sans restriction sur l’intégralité des 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 calculs hydrologiques,
http://downloads2.esri.com/support/datamodels/Hydro/ArcHydro13.zip) s’intégrant à
l’IHM standard (sous forme d’une barre d’outils pour Archydro), mais aussi de
personnaliser le modèle ESRI de géodatabase à travers 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 comportement des entités de la
géodatabase en réaction aux évènements de mise à jour (création, modification,
destruction d’entités).
La compilation du code présente deux intérêts majeurs:

• 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 application, c'est-à-dire de

recompiler tous les Arcobjects en y intégrant ses propres 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 la 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 trouverez un guide pour développer

un composant en VB ou VB.NET

N.B : les ArcObjects sont des composants COM ; l’environnement .Net (le .Net
framework) ne travaille pas directement avec ces composants mais avec des
assemblies fournies par Esri, qui encapsulent de manière intelligible pour lui la
ressource COM. Cette couche supplémentaire ne diminue 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/index.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 processus (Modelbuilder)
• un environnement d’exécution par ligne de commande
• un environnement de création et d’exécution de scripts (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 à ArcToolBox ou encore de créer
graphiquement un outil avec Modelbuilder et le modifier ensuite dans
l’environnement de script.
Tout utilisateur d’Arcgis est un consommateur potentiel d’outils de géotraitement.

Chaque opération de géotraitement consiste à transformer 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 élaboré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 distribution de données
spatiales
• la recherche de zones propices aux glissements de terrain
• l’évaluation d’un aléa (inondation, incendie)
II.1.1.3.1. ModelBuilder
ModelBuilder permet de créer des modèles graphiquement 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é en 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_mod
el
ModelBuilder est un vrai environnement de programmation 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éotraitement, les secondes
stockent les autres informations utiles aux outils). Ce mécanisme permet de
développer des processus de traitement paramétrables, capables d’agir sur des
données différentes, dans des conditions éventuellement différentes.
• Les variables sont typées
• il offre toutes les structures de contrôle de la programmation structurée :
conditions, boucles
Développons ce dernier point : s’il est vrai que certains 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 traitée par le modèle est en entrée
de deux sous-processus (voir ci-dessous) : il y a alors deux branches dans
lesquelles vont s’exécuter des traitements. Ces 2 branches 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 doit donc s’exécuter dans un
certain ordre.

ModelBuilder depuis la version 9.2 propose plusieurs 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éographique.
En résumé, les modèles peuvent être étonnamment complexes (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écouper 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 alternative, 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 compatibles, toutefois c’est Python
qui a la préférence d’Esri et des développeurs ArcGIS 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 comprises) 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 Python et de les exécuter depuis une
IHM développée en VB. Pour cela il suffit d’instancier 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 tous 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_Programm
ing_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 reliant 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 possible 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 caractère #.
Une des caractéristiques est l’utilisation du caractère tabulation comme élément du

langage. Là où dans la plupart des langages, l’indentation n’est qu’une convention
d’écriture destinée à améliorer la lisibilité du code, 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 que pour du développement en
mode compilé mais sensiblement les mêmes que pour du code VB interprété par
VBA.
• il y a une large communauté de développeurs de scripts Python et on peut
trouver sur internet de nombreux outils tout faits : le site edndoc.esri.com
met notamment à disposition de nombreuses ressources à la rubrique Code
Exchange (ArcScripts)
Le débutant trouvera sur le site resources d’ESRI tout ce qu’il faut pour s’initier
au développement de modèles ou scripts de géotraitement
(http://resources.esri.com/geoprocessing/).
II.1.2. Création d’applications

Il s’agit ici de créer une application SIG originale (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 façon à simplifier l’accès
d’un utilisateur novice à des fonctions SIG.
• marier certaines fonctionnalités SIG, telles la visualisation sous forme de
cartes ou encore la capacité à rechercher des informations sur critères
spatiaux à d’autres types de traitements (traitement 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 application 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 relativement aisé puisque le

développeur dispose de 7 controls de haut niveau (controls 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 services 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 établies, Manager permet de régler les
paramètres de publication (informations attributaires retournées par une requête
résultat), choisir les outils, donc le type d’interactivité, 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 pour l’essentiel en asp et pour
partie en Javascript. Cette application est codée selon les standards du web 2.0 :
elle utilise donc la technologie Ajax pour les échanges 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 actions utilisateurs (changement
d’échelle, modification de la visibilité des couches, recherche d’objets).

Cela étant, on peut très rapidement avoir envie d’aller au-delà de ce type
d’application et ce pour plusieurs raisons :
• le manque de fonctionnalités : dans la vue ci-dessus, mis à part les outils

standards de navigation, il n’y a qu’un outil « métier » permettant la
recherche d’un hôpital par son nom. On aurait pu proposer 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 donné n’existe pas en
standard.
• Le design ne correspond pas à ce qu’on souhaite
• On aimerait créer une application mashup avec d’autres ressources que celles
citées précédemment, en particulier avec les données de fond de plan tirées
des banques Google ou Virtual Earth.
Il convient alors de développer une application originale. 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’entré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 Javascript

C’est le bon outil pour celui qui débute en développement de solutions de

webmapping autour des technologies ArcGIS. C’est aussi la bonne solution si le
cahier des charges n’impose pas de développer des fonctionnalité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 ArcGIS. 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’exé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 de 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 XML), Javascript permet de
programmer la réaction aux évènements en conservant une bonne fluidité de
navigation (pas de rechargement de tous les éléments 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 interactions avec l’utilisateur.
Toutes les données peuvent être issues du même serveur ou bien de serveurs
différents. Il est notamment possible d’accéder à des 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 des 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/services) proposant des fonds de carte
d’extension mondiale de toutes sortes. Certaines données sont en accès libre,
d’autres font l’objet d’une tarification. A noter que tous les exemples
d’application proposés par le centre de ressources utilisent ces services.

L’API permet également des consommer d’autres services et notamment des services
OGC.
L’API communique avec les serveurs à l’aide du protocole Rest : pour accéder à une
ressource (ou service) avec l’API, il faut donc connaî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 ArcGIS à 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 Object 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 particulièrement recommandé dans le
cadre d’une interaction avec un programme Javascript. Les données JSON sont en
effet parsées environ 100 fois plus vite que les donné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. fonctionne en mode asynchrone

permettant l’échange d’informations en tâches de fond entre le client et le
serveur. L’API prend totalement en charge tous ces aspects de la
communication client-serveur; elle met à disposition du développeur des objets
chargés d’émettre les requêtes vers des urls et d’exploiter 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 de développement Javascript open
source plus générique sur lequel l’API est construite. Ce kit est le Dojo.
Le Dojo permet avant tout de s’abstraire des particularités propres à chaque

navigateur et donc de pouvoir écrire un code générique, interprété par tous les
navigateurs. Il permet également de disposer de fonctions 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 rapide 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 standard
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 tableaux (DataGrid) avec des colonnes
triables, etc… Il est nécessaire de connaître un certain nombre de fonctions Dojo
pour interagir avec les serveurs ArcGIS dans le cadre de cette API :
• Dojo.require : permet de charger une ressource Javascript. 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 une 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 portant sur un objet ou un
élément de la page. C’est l’équivalent des fonctions Javascript
addEventListener et attachEvent.
• Dojo.ById(« monControlInput »).value = « texte à stocker ». 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 tirer 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 données de type carte servies par
des serveurs ArcGIS aux couches de base Google ou Microsoft : 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 aussi d’exploiter des services de
géotraitement, de géocodage et d’afficher les résultats sur ces fonds de plan.
L’API Google Maps offre en plus la possibilité de valoriser sous forme de
diagrammes statistiques les données attributaires des données SIG à l’aide API

Google Chart mais aussi de diffuser largement son application sous forme d’une
mapplet.
Il est enfin possible de télécharger sur le site resources d’ESRI une application
Javascript modèle, le Javascript viewer, intégrant de nombreux composants
d’interface
(http://resources.esri.com/arcgisserver/apis/javascript/arcgis/index.cfm?fa=codeGal
leryDetails&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 contenu (les couches de données)
mais aussi l’IHM et tout ça sans programmer une seule ligne de code !! Il s’agit
d’une application riche exploitant pleinement les technologies du web 2.0 et qui
s’apparente par bien des aspects aux applications Flex ou Silverlight.
S’il est vrai qu’un simple éditeur de texte peut suffire à 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’API 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 conception 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 bureautique. Les solutions Javascript,
même avec les améliorations liées à la généralisation d’Ajax n’offrent pas encore
tout à fait cette fluidité et cette qualité d’interactivité avec les données.
Toutefois, il existe des inconvénients : le navigateur client ne suffit pas pour
exécuter de telles applications ; il faut ajouter un plug-in. Ce qu’on gagne en
interactivité, on le perd en vitesse de connexion au site.
II.2.3.1. API Flex

L’API Flex pour ArcGIS est bâtie sur l’environnement 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 version 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 puisque le kit de développement Flex
est sous licence. Comparativement à l’API Javascript, 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 :initialize)
<mx:Script>
<![CDATA[
import mx.controls.Alert;
private function onMapLoad():void
{
Alert.show('Bonjour!');
}
]]>
</mx:Script>
• En important une bibliothèque ou une classe ActionScript
include "myextracode.as";
Le code doit ensuite être compilé en swf.
Pour utiliser l’API il faut télécharger l’API (il suffit 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 centre de ressources et le site

d’adobe. Sur ce site, on trouve en particulier en téléchargement l’application
bureautique Tour de Flex qui illustre les capacités de cet outil et notamment en
terme d’exploitation cartographique (rubrique mapping).
Signalons enfin qu’ESRI met à disposition une application template, le Sample Flex
Viewer que l’on peut télécharger sur le site resources.esri.com. Cette application
est développée de telle sorte qu’il est possible sans 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’outil 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érer le fichier compilé (swf) avec
Flash Builder.

II.2.3.2. API SilverLight
D’un point de vue technique, l’API est construite en 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. Pour l’utiliser, il faut donc
avant tout télécharger l’API Silverlight (http://silverlight.net/). Silverlight est
la solution concurrente de Flash. Toutefois, il s’adresse avant tout à la famille
de développeurs Microsoft : en effet, une telle application 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# .Net permet de coder les
traitements.
Tout comme les APIs Javascript ou Flex, l’API Silverlight 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 sont des API qui dialoguent avec le
serveur selon le protocole REST, i.e. qui déclenchent 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 essentiellement 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’avec des ressources hébergées sur
son propre domaine. Il permet enfin d’accéder à toute la richesse fonctionnelle du
SIG : l’API REST n’expose en effet que les fonctionnalités les plus courantes
Avec une application web 3 tiers, il devient donc possible de proposer des
traitements lourds (calculs) mais aussi de l’édition de données (saisie en base,
mise à jour), notamment dans un contexte d’accès multi-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 changent entre les deux.
Un framework, c’est un ensemble d’outils s’intégrant à un environnement de

développement. Le Web ADF pour .Net s’intègre à Microsoft 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 à outils (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é : glisser-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 sur 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 ArcGIS).
Les applications développées avec le web ADF .NET se déploient sur le serveur web
IIS.
Nous avons vu précédemment qu’ArcGIS Server est livré avec une application, le
Manager, qui permet de créer un client web. Une telle application est développée à
partir du web ADF : c’est une application 3 tiers comprenant 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 obtient la même chose qu’avec le

Manager. L’annexe 5 explique cela. Pour plus d’informations se référer aux

tutoriels du centre de ressources.
Une troisième solution consiste enfin à créer une application de toute pièce à
partir des composants de la boîte à outils.
Le Web ADF permet de créer des applications qui interagissent 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 dispose de plusieurs API : une API
commune à toutes les sources qui regroupe les fonctionnalités que l’on retrouve
chez chacune d’entre elles (ex : obtenir une carte, obtenir les informations
attributaires), des APIs propres à chacune des sources pour les fonctionnalités
spécifiques (API ArcObjects par exemple pour calculer un itinéraire optimisant une
tournée ou encore pour des calculs qui exploitent la 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 possibles autour d’ArcGIS Server et
de la consommation par un client de ressources distantes, ainsi que le montre
l’illustration suivante.

Il est notamment possible de développer à partir des 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 mais 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 logiciels, 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 fonctionnalités SIG proposés par les
produits de la gamme ArcGIS.
Ils ont été développés conformément aux prescriptions de la norme COM. C’est cette
norme, entre autres, qui permet la réutilisation des 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 nature : il y a celle qui propose les
traitements relatifs à l’affichage de données, celle qui s’occupe de l’accès aux
données, … Certaines sont partagées par les différents produits (bureautique et
serveur) ; d’autres sont propres à chacun (les bibliothèques xxxUI sont propres à
ArcGIS bureautique ; elles spécifient les composants 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éographiques, 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 ressources qu’il diffuse, ArcWeb permet
d’accéder aux services web hébergés par les serveurs 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 construits à 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 programmer 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 logiciels. 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 aspect du logiciel sans le
remettre en cause.
ESRI a choisi COM il y a quelques années car c’était 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 derriè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 client 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 des classes COM : les instances
de ces classes peuvent donc jouer le rôle de serveur 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écifiés à travers des interfaces,
avec lesquelles le client interagit. Il y a des milliers de propriétés et méthodes
ainsi exposées par les interfaces.
Les ArcObjects sont à tour de rôle serveur et client selon la situation. C’est ce
que montre le schéma suivant : imaginons que l’on souhaite 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 ArcMap. 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 composants ont été développés ; dans
la mesure où ils implémentent les fonctionnalités pré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 espace de processus, c’est le cas
pour des objets de type DLL. A contrario, l’objet et 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 composants 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 les ArcObjects, il n’accède pas
directement aux classes d’objets (les serveurs) mais communique avec elles à
travers les interfaces qu’elles implémentent.
Une interface peut être définie comme la spécification 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 regroupement logique de fonctions
virtuelles qui servent uniquement à établir la communication entre un serveur
et ses clients.
Une fois publiée, la signature d’une interface ne peut 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ètement un algorithme : ces
modifications nécessiteront simplement de recompiler les composants (dll) qui
implémentent l’interface, les clients n’étant pas affectés par cette mise à jour.
S’il s’avère nécessaire de publier de nouvelles fonctionnalités, alors il s’impose
• De créer de nouvelles interfaces
• D’implémenter ces interfaces par les composants existants ou bien par de
nouveaux composants
Au fil des mises à jour logicielles, certaines interfaces 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 exposé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 :
IBirth IWalk
IDeath
ITalk
Ifly
IBirth IBirth IBirth
ITalk IWalk
ITalk
IWalk IDeath
IFly
IDeath
Enfin COM supporte le concept d’héritage entre classes ce qui est le troisième
principe de l’orienté-objet.

III.3.3. L’interface IUnknown et les autres

Tous les serveurs COM implémentent l’interface IUnknown 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 instance (méthode
QueryInterface)
En plus de cette interface IUnknown, les ArcObjects implémentent d’autres

interfaces qui exposent les fonctionnalités SIG. Parmi toutes les interfaces
implémentées, une joue le rôle d’interface par défaut.
Lorsqu’un client crée une instance, il accède à cette 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 serveur COM comme un cube, dont
chacune des faces est une interface. Un client ne peut voir qu’une face en même
temps : c’est pourquoi lorsqu’il établit la communication, 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émenté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 interfaces 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’interface, 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 partie) 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 interface donnée.
A ces diagrammes, s’ajoutent deux autres ressources complémentaires :

• les browsers intégrés aux environnements de développements (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’objets :

• La classe abstraite : elle ne peut pas être instanciée. Elle expose des
propriétés et méthodes génériques, communes à plusieurs autres classes, qui
structurellement lui sont reliées par un lien d’héritage.
Les classe Geometry, Layer et Dataset sont 3 exemples de classes

abstraites : on ne peut pas créer d’instances Geometry, 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 (voir 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 peut ê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 : elles 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 implémentées par les classes. Les
inbound et outbound interfaces sont différenciées. Les héritages d’interface 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 classe et des formulaires.
L’environnement VBA facilite le travail du développeur, en ce sens que les

ArcObjects sont déjà référencés. Par ailleurs la machine 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 doté 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ègles :
• 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 les propriétés exposées par
une classe ; mais ça nuit à la lisibilité du code.
• Les paramètres des procédures et fonctions sont passé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 ArcObjects), déclarer une
variable pointeur sur une des interfaces implémentées par la classe ;
instancier ensuite votre variable à l’aide du mot clé 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, regarder le type de la

propriété. Si c’est une interface, déclarer une variable 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 et max) de la zone
actuellement cartographiée ; il faut travailler avec 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, regarder si la méthode renvoie ou
non une valeur. Si oui déclarer une variable du même 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 concernant des controls

personnalisés (ceux ajoutés par l’outil de personnalisation 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éclarer les sous forme de
propriétés privées à la structure et implémenter sur 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 serveurs) 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’agisse 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 balance 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 population 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 à chacune 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 conceptuel 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’est 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 membres : 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, structurées sous forme de procédures

et de fonctions.
Un module de classe décrit une classe au sens orienté-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 nombre de controls (boutons,
liste déroulante) auxquels est associé du code événementiel.
Tout document comporte également un projet Normal qui est un template, contenant
tous les éléments d’interface standards, ainsi qu’un 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 template 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 une 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êtres. Il est possible de copier-

coller du code d’une fenêtre à l’autre. Il est également possible d’importer un
élément de l’un des 3 types mentionnés depuis un fichier 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, chacune étant du type sub, function
ou property (les « getter » et « setter » pour lire et écrire les 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 variable. 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 globales quant à elles persistent
tant que le programme tourne.
Si on souhaite créer une IHM, on insére un module de type formulaire, puis on fixe
graphiquement le contenu de celui-ci en piochant parmi les controls proposés par la
boîte à outils.
N.B : il est possible d’ajouter tout control référencé dans la base de registres.
Ensuite, dans la fenêtre de code attaché au formulaire, 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. pour empêcher tout utilisateur du
document de le voir et donc de le modifier, il suffit 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 curseur dans la procédure puis
exécuter. Une alternative consiste à ajouter à l’interface du document ArcMap un

bouton personnalisé de type Custom Control>Button Control et à déclencher le code

en réaction à l’évènement clic sur ce nouveau control.
Il y a un environnement de déboggage : ajout de points 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 document ArcMap ouvert, en tant
qu’instance de la classe MxDocument.
Pour de plus amples explications, ainsi qu’une prise 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 programmation. Afin de charger dans
l’environnement de développement VB tous les adds-in, il suffit d’exécuter
registervbaaddins.exe que l’on trouve dans le répertoire addins du kit de
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’instanciation :
Charger ensuite les bibliothèques ESRI requises pour le développement (aller dans
Projet>References).
Il est en effet nécessaire de référencer les ArcObjects (classes, interfaces) qui

n’ont aucune raison d’être connus de l’IDE. Selon ce que l’on veut programmer, il
faut charger un plus ou moins grand nombre de bibliothè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 Spatial 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 les 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 type Inbound.
Pour certaines interfaces, ça peut être relativement 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 prototypes 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 variables globales dans la méthode
class_terminate du module de classe.
Il faut enfin compiler le code pour fabriquer la dll : 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 instancie 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. On

va utiliser un template pour créer une nouvelle classe 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électionner 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 parler. Nous allons utiliser des

snippets ArcGIS, i.e. des morceaux de code directement réutilisables. 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 cliquant sur le signe « - » dans la
marge gauche.

La procédure ainsi ajoutée permet de modifier l’étendue de la fenêtre

cartographique. Cette procédure a un paramètre : une référence vers le document
ArcMap ouvert.
Pour obtenir une référence vers le document, nous allons utiliser un deuxième
extrait de code : ArcGIS bureautique>mapping>Map documents>Get MxDocument from
ArcMap.
Ce code permet d’obtenir la référence vers le document à 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-dessus dans la méthode OnClick qui
sera appelée en réaction au clic utilisateur sur notre 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 sorte que notre classe soit reconnue
comme une classe COM (on rappelle que tous les composants 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 en 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. Enregistrer 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 liens est un composant DLL stocké

dans le sous-dossier bin>Release.

On peut maintenant intégrer la commande à l’IHM d’ArcMap. 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 dans l’explorateur.
Ajouter ensuite un point d’arrêt sur une instruction 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 une 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 utilisateurs 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 interfaces 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 lorsque la sélection courante
d’entités change ; ou bien quand l’on numérise de nouvelles 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 permettent au client
de faire appel à des fonction implémentées par l’objet. 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 particulier l’interface
IObjectClassEvents laquelle permet de traiter les évènements de création ,
modification et destruction relatifs à tous les types d’entités.

En guise d’exemple, si l’on souhaite prendre en charge (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 global 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ènements 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 for: " & obj.OID
End Sub
Private Sub pObjEvent_OnDelete(ByVal obj As IObject) MsgBox "OnDelete for: " & 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 plus nombreuses, on les retrouve
néanmoins sur un certain nombre de classes ArcObjects. 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 interactif 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 pour 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 écoute les évènements

' générés par l’objet Editeur du document ArcMap courant
Public Sub InitEvents()
'la classe ArcObject Editor est une classe simple; pour obtenir un
'pointeur sur un objet de cette classe il faut donc passer
'un autre objet : ici par l’objet Application Dim pUID As New UID
pUID = "esriEditor.Editor"
Set pEditorEvent = Application.FindExtensionByCLSID(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 As 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éé au préalable.
Démarrer Visual Studio 2005 et créer un nouveau projet 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’interface 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 ressources 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/html; charset=utf-8"/>
<link rel="stylesheet" type="text/css"
href="http://serverapi.arcgisonline.com/jsapi/arcgis/1.4/js/dojo/dijit/themes/tundra/tundra.cs
s">
<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/services/ESRI_StreetMap_World_2D/MapServer");
myMap.addLayer(myTiledMapServiceLayer);
}
dojo.addOnLoad(init);
</script>
</head>
<body>
<div id="mapDiv" class="tundra" style="width:900px; 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 composant 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éation de la carte
interactive.
• La réponse à l’évènement de chargement de la page web dans le navigateur.
Ici, la réponse à l’évènement est prise en charge par 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 aux différentes actions de
l’utilisateur. La programmation est donc essentiellement à base d’évènements.
Parmi les évènements gérés, il y a ceux qui sont traités immédiatement et ceux qui
sont traités en mode asynchrone après un aller-retour avec le serveur (principe
AJAX).
Quel que soit l’évènement, afin de le prendre en charge, il faut ajouter du code
qui « écoute », à savoir du code qui permet de déclencher 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éthode 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éfinir un écouteur pour l’évènement

clic sur l’objet map ainsi que le nom de la fonction traitant l’évènement.
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 :
<html>
<head>
<title>Create a Map</title>
s">
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://server.arcgisonline.com/ArcGIS/rest/services/ES
RI_StreetMap_World_2D/MapServer");
myMap.addLayer(myTiledMapServiceLayer);
}
function monClicHandler(event) {
alert("L'utilisateur a cliqué en " + event.mapPoint.x + "," +
event.mapPoint.y);
}
function monOnUnloadHandler(event) {
dojo.disconnect(monClicHandler);
}
</script>
</head>

<body>
<div id="mapDiv" class="tundra" style="width:900px; 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 dynamiquement

en WMS
Le code suivant étend les possibilités entrevues dans le premier extrait de code.
Il montre comment paramétrer l’extension spatiale de la vue cartographique (alors
que le code précédent affiche toute l’étendue spatiale de la couche de base). Il
permet surtout de superposer à une couche de base servie 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 permet d’afficher que des données
servies par des serveurs ArcGIS selon les protocoles 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/html; charset=utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=7" />
<title>WMS</title>
href="http://serverapi.arcgisonline.com/jsapi/arcgis/1.4/js/dojo/dijit/themes/soria/soria.css"
>
dojo.declare("pgwWMSLayer", esri.layers.DynamicMapServiceLayer, {
constructor: function() {
this.initialExtent = this.fullExtent = new esri.geometry.Extent({xmin:-180,ymin:-
90,xmax:180,ymax:90,spatialReference:{wkid:4326}});
this.spatialReference = new esri.SpatialReference({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-bin/icedswms?"+dojo.objectToQuery(params));
}
})
dojo.declare("brgmWMSLayer", esri.layers.DynamicMapServiceLayer, {
this.initialExtent = this.fullExtent = new esri.geometry.Extent({xmin:-
10,ymin:40,xmax:15,ymax:52,spatialReference:{wkid:4326}});
this.spatialReference = new esri.SpatialReference({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/limitesadm?" + dojo.objectToQuery(params));
}
})
-->
function init() {
var map = new esri.Map("map");
var startExtent = new esri.geometry.Extent(-6.062580, 41.163200, 10.878300,
51.291800,new esri.SpatialReference({wkid:4326}) );
map.setExtent(startExtent);
map.addLayer(new
esri.layers.ArcGISTiledMapServiceLayer("http://server.arcgisonline.com/ArcGIS/rest/services/ES
RI_Imagery_World_2D/MapServer"));
var pgwLayer = new pgwWMSLayer();
pgwLayer.setOpacity(.75);
map.addLayer(pgwLayer);
map.addLayer(new brgmWMSLayer());
}
</script>
</head>
<body>
<div id="map" class="soria" style="position:relative; width:1024px; height:512px;
border:2px solid #000;"></div>
</body>
</html>
Commentaires :
Dans le code précédent, on crée une carte avec trois sources de données
dynamiques :
• Les données mondiales image 2D du serveur arcgisonline

• La carte de densité de population en 2005 du serveur WMS
http://iceds.ge.ucl.ac.uk/cgi-bin/icedswms?
• La carte des limites administratives départementales et communales du serveur
WMS http://swing.brgm.fr/cgi-bin/limitesadm?
Pour prendre en charge les couches WMS, on crée deux 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 nouvelle 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éation 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 couche 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 les
widgets du Dojo.
Code :

<html>
<head>
<title>Afficher des données OpenStreetMap</title>
s">
var djConfig = {
parseOnLoad: true
}
</script>
dojo.require("dijit.form.Slider");
var map, layer1, layer2;
//pour en savoir plus
http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/arcgis/help/jshelp/inside_cust
om_layers.htm
dojo.declare("OpenStreetMapLayer", esri.layers.TiledMapServiceLayer, {
//constructeur de la nouvelle couche
this.spatialReference = new esri.SpatialReference({
"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.591555,
"resolution": 156543.033928
}, {
"level": 1,
"scale": 295828763.795777,
"resolution": 78271.5169639999
}, {
"level": 2,
"scale": 147914381.897889,
"resolution": 39135.7584820001
}, {
"level": 3,
"scale": 73957190.948944,
"resolution": 19567.8792409999
}, {
"level": 4,
"scale": 36978595.474472,
"resolution": 9783.93962049996
}, {
"level": 5,
"scale": 18489297.737236,
"resolution": 4891.96981024998
}, {

"level": 6,
"scale": 9244648.868618,
"resolution": 2445.98490512499
}, {
"level": 7,
"scale": 4622324.434309,
"resolution": 1222.99245256249
}, {
"level": 8,
"scale": 2311162.217155,
"resolution": 611.49622628138
}, {
"level": 9,
"scale": 1155581.108577,
"resolution": 305.748113140558
}, {
"level": 10,
"scale": 577790.554289,
"resolution": 152.874056570411
}, {
"level": 11,
"scale": 288895.277144,
"resolution": 76.4370282850732
}, {
"level": 12,
"scale": 144447.638572,
"resolution": 38.2185141425366
}, {
"level": 13,
"scale": 72223.819286,
"resolution": 19.1092570712683
}, {
"level": 14,
"scale": 36111.909643,
"resolution": 9.55462853563415
}, {
"level": 15,
"scale": 18055.954822,
"resolution": 4.77731426794937
}, {
"level": 16,
"scale": 9027.977411,
"resolution": 2.38865713397468
}]
});
//étendue spatiale totale de la couche.
this.fullExtent = new esri.geometry.Extent({
"xmin": -20037508.34,
"ymin": -20037508.34,
"xmax": 20037508.34,
"ymax": 20037508.34,
"wkid": 102113
}
});
//étendue spatiale initiale de la couche
this.initialExtent = new esri.geometry.Extent({
"xmin": -35222182.633799955,
"ymin": -19567879.240999974,
"xmax": 35222182.633799955,
"ymax": 19567879.240999974,
"wkid": 102113
}
});
//url des serveurs de tuiles openStreetMap
this.servers = ["http://a.tile.openstreetmap.org/",
"http://b.tile.openstreetmap.org/", "http://c.tile.openstreetmap.org/"];
this.serversLength = this.servers.length;
this.serverIndex = 0;
this.loaded = true;
this.onLoad(this);
},
getTileUrl: function(level, row, col) {
//retourne la dalle en cache sur le serveur correspondant aux numéros de
ligne et colonne indiqués
return this.servers[this.serverIndex++ % this.serversLength] + level + "/"
+ col + "/" + row + ".png";
}
});
function init() {

var startExtent = new esri.geometry.Extent(-600284.1078298639,

5947637.185194191, 622708.3447326261, 6926031.147244183, new esri.SpatialReference({
wkid: 102113
}));
map = new esri.Map("map", {

extent: startExtent
});
layer1 = new OpenStreetMapLayer();
map.addLayer(layer1);
layer2 = new
esri.layers.ArcGISDynamicMapServiceLayer("http://sampleserver1.arcgisonline.com/ArcGIS/rest/se
rvices/Demographics/ESRI_Population_World/MapServer", {
opacity: 0.3
});
map.addLayer(layer2);
dojo.connect(map, "onMouseMove", function(evt) {
dojo.byId("coords").innerHTML = "X: " + evt.mapPoint.x + " | Y: " +
evt.mapPoint.y;
});
var slider = new dijit.form.HorizontalSlider({
name: "slider",
value: 3,
minimum: 0,
maximum: 10,
intermediateChanges: true,
discreteValues: 11,
showButtons: true,
style: "width:200px;",
onChange: function(value) {
layer2.setOpacity(value / 10);
dojo.byId("opval").innerHTML = value / 10;
}
}, "slider");
}
</script>
</head>
<body class="tundra">
<h2>Extension de la classe de couche TiledMapServiceLayer afin d'ajouter les donnees
OpenStreetMap</h2>
<p>
Dans cet exemple les donnees OpenStreetmap sont ajoutees comme couche de base
tandis que les donnees de population hebergees par un serveur Esri ArcGISOnline sont
superposees dessus. Utiliser la barre pour definir la niveau de transparence de la couche en
superposition.
<a
href="http://resources.esri.com/help/9.3/arcgisserver/apis/javascript/arcgis/help/jshelp/insid
e_custom_layers.htm">Plus de documentation sur le centre de ressources Esri </a>
</p>
<div id="coords" style="font-size:9pt; color:gray;">
</div>
<div id="map" style="width:800px; height:400px; border:5px solid #ccc;">
</div>
<p>
Modifier la transparence de la couche population (<span id="opval">0.3</span>)
<div id="slider">
</div>
</p>
</body>
</html>
Commentaires :
Tout comme dans l’exemple précédent, on étend ici à l’aide du dojo un type de
couches (tuiles) gérée par défaut par ArcGIS Server. Cette extension de classe
permet ici de charger les tuiles OpenStreeMap stockées sur des serveurs Mapnik.
L’application de webmapping à proprement parler contient quatre div superposées :

• Une pour afficher les coordonnées du curseur
• Une pour afficher la carte, laquelle contient 2 couches d’informations : le
fond de plan OpenStreetMap et les données de densité de population servies
par un serveur ArcGIS Online.
• Une pour afficher le niveau de transparence
• Une pour afficher la barre permettant de régler le niveau de transparence
L’affichage des coordonnées du curseur est géré dynamiquement par le dojo sous
forme d’un évènement OnMouseMove.

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 avantages 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 ArcGIS pour l’API Google Maps afin
d’exploiter les résultats d’une interaction avec un serveur ArcGIS sur un fonds
Google Maps.
Code :
<html debug=true>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Query Task (Returns Point)</title>
<script
src="http://maps.google.com/maps?file=api&v=2&key=DioG219lPJG3WTn3zmQqebsjVg"
type="text/javascript"></script>
<script src="http://serverapi.arcgisonline.com/jsapi/gmaps/?v=1.4" type="text/javascript"
></script>
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('gmap'));
gmap.addMapType(G_NORMAL_MAP);
gmap.addMapType(G_SATELLITE_MAP);
gmap.addControl(new GLargeMapControl());
gmap.addControl(new GMapTypeControl());
gmap.setCenter(new GLatLng(33.96964806519751, -117.37674951553345), 17); // RIVERSIDE
(Point)
gmap.enableScrollWheelZoom();
//instanciation du mapExtension
mapExtension = new esri.arcgis.gmaps.MapExtension(gmap);
// instanciation du Query Task

qtask = new
esri.arcgis.gmaps.QueryTask("http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demogr
aphics/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 ArcGIS Server instancié
qtask.execute(query, false, mycallback);
}
function mycallback(fset) {
var myMarkerOptions = {
title: "2000 Population: {POP2000}"
}

var overlayOptions = {
markerOptions:myMarkerOptions
};
var infoWindowOptions = {
content:"Population = {POP2000}<br/>Nombre de ménages = {HOUSEHOLDS}<br/>Nombre de
maisons = {HSE_UNITS}"
};
// ajout des entités résultats sous forme de markers
gOverlays = mapExtension.addToMap(fset);
}
</script>
</head>
<body onload="initialize();" onunload="GUnload();">
<table width="100%" height="100%">
<tr>
<td align="center">
<table>
<tr align="left">
<td>
<input type="button" value="Rechercher les ilôts" onclick="executeQuery();"
/>
<input type="button" value="Effacer les marqueurs"
onclick="mapExtension.removeFromMap(gOverlays);" />
</td>
</tr>
<tr align="left" valign="top">

<td>
<div id="gmap" style="width: 500px; height:500px;"></div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Commentaires :
L’exemple permet d’interagir avec une couche de points d’un service de carte
hébergé par un serveur ArcGIS. Lorsqu’on charge l’application, le fonds Google Maps
s’affiche ; lorsqu’on clique sur le bouton « Rechercher les ilots », des markers
matérialisant les centroïdes des ilots de recensement aux Etats-Unis (les census
block points pour être précis) apparaissent. Si on clique sur l’un d’entre eux, un
popup d’informations apparaît. Le bouton « Effacer les marqueurs » permet de
détruire les marqueurs.
Le code contient trois fonctions Javascript :

• La fonction initialize qui crée la carte Google Maps, centrée et mise à
l’échelle tel que souhaité. Cette fonction instancie également un objet
MapExtension permettant l’interaction avec ArcGIS Server ; cela se traduit
ici par la capacité à afficher les résultats d’une requête ; pour ce faire il
est nécessaire d’instancier un objet QueryTask destiné à stocker l’url du
service permettant d’accéder aux données de recensement (la couche des block
points est ici identifiée par le numéro O), puis un objet Query.
• La fonction executeQuery qui est exécutée en réaction au clic sur le bouton
« Rechercher les ilôts ». Elle récupère les coordonnées du rectangle
englobant de la vue courante, spécifie la requête (étendue spatiale, champs à
récupérer) puis l’exécute.
• La fonction mycallback qui est exécutée après exécution de la requête et qui
traduit les résultats sous forme de markers ; elle paramètre en outre le
contenu des popups obtenus par clic ou passage de la souris sur les markers.

Cours Arcgis Developpement

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours Arcgis Developpement

Uploaded by

Copyright:

Available Formats

Cours

Alexandre Pauthonnier 3/82

Par ailleurs, l’évolution récente du monde de l’information géographique vers la

La force d’ArcGIS tient aussi en grande partie à sa large communauté

Alexandre Pauthonnier 4/82

I. Présentation brève d’ArcGIS

I.1. Les applications bureautique

Alexandre Pauthonnier 5/82

• Diffuser les données dans divers formats

Il existe 3 niveaux de licence qui donnent accès à plus ou moins d’outils :

De nombreux tutoriels, sous forme de documents pdf et de vidéo sont accessibles en

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

I.2. Les applications serveur

Il s’agit de mettre à disposition de plusieurs membres d’une même organisation, ou

Cette technologie s’appuie sur le modèle de communication client-serveur utilisant

Cette technologie serveur est complémentaire de la technologie bureautique, en ce

Alexandre Pauthonnier 6/82

ArcGIS comprend 2 produits serveurs : ArcGIS Serveur et ArcIMS qui ne s’inscrivent

C’est un serveur cartographique permettant de publier de la cartographie dynamique

La communication client-serveur repose sur un flux XML (ArcXML). On peut accéder

I.2.2. ArcGIS Server

Alexandre Pauthonnier 7/82

La logique de service permet de passer d’une architecture client-serveur à une

Pour publier un geoprocessing service, il y a 2 façons de procéder : soit on crée

Alexandre Pauthonnier 8/82

privilégiera donc la deuxième solution. Il est possible aussi d’associer un

Pour publier un geocode service, il faut créer au préalable un locator ou

On administre les services (création, arrêt, démarrage, paramétrage) à l’aide

Ainsi qu’on l’a évoqué précédemment, la logique de service va également de pair

Alexandre Pauthonnier 9/82

L’interopérabilité se manifeste également par la publication des services selon les

A chaque service est associée une url selon le modèle suivant

http://<nom du serveur>/<nom de l’instance arcgis server>/services/<nom du

et plusieurs urls complémentaires pour chaque type d’interopérabilité

http://<nom du serveur>/<nom de l’instance arcgis server>/services/<nom du

où capability désigne le type d’interopérabilité

les urls suivantes

Pour accéder en REST aux services, on utilise le service de catalogage REST du

Alexandre Pauthonnier 10/82

N.B : il est nécessaire d’exécuter la web application post-installation pour

L’interopérabilité est un des nombreux paramètres à considérer lorsqu’on publie une

Alexandre Pauthonnier 11/82

Il convient aussi de réfléchir à l’opportunité de pré-calculer un cache pour les

Le troisième et dernier rôle d’ArcGIS Server consiste à permettre la création

Ou bien de clients personalises

Alexandre Pauthonnier 12/82

ArcGIS Server est commercialisé en 3 niveaux de licence : Basique, Standard et

Advanced Standard Basique

Gestion des données

Fournit des services de géodonnées permettant aux administrateurs de publier

Services Web SIG

Comprend des outils de création d'applications web cartographiques riches

Prend en charge les analyses et les géotraitements serveur, avec notamment

Prend en charge un large éventail de clients, notamment ArcGIS Desktop,

Gestion des images

Supporte un système complet de gestion des images permettant la mise à

Fonctionnalités d'application Web

Alexandre Pauthonnier 13/82

Comprend des outils et des tâches, dont le zoom et les déplacements

Analyse spatiale avancée

Intègre la modélisation et l'analyse spatiales avancées, avec notamment

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

Outils de développement d'applications nomades