Professional Documents
Culture Documents
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
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.
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.
On distingue :
• Les applications bureautiques
• Les applications serveur
• Les applications mobiles
• Les services web hébergés
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.
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Tutorials
• partager le SIG
• intégrer le SIG dans le système d’information de l’entreprise.
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
I.2.1. ArcIMS
Quelques mots de présentation malgré tout.
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).
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.
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.
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.
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.
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.
soit pour un service de carte nommé test_arcpad, contenant des couches de type
vecteur et raster, et hébergé sur le serveur monserveur
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.
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.
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)
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.
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
Analyse spatiale
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
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
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.
On retiendra également que les avantages d’une solution SIG serveur sur une
solution bureautique tiennent essentiellement aux points suivants :
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.
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?).
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.
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.
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).
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.
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.
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.
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.
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
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.
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")
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.
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 #.
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/).
Il est possible de travailler avec des IDE Windows (COM ou .NET), mais aussi avec
des IDE Java, tels Eclipse et JBuilder.
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).
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 :
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 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.
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.
<mx:Script>
<![CDATA[
import mx.controls.Alert;
private function onMapLoad():void
{
Alert.show('Bonjour!');
}
]]>
</mx:Script>
include "myextracode.as";
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).
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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é.
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.
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
IBirth IWalk
IDeath
ITalk
Ifly
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.
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.
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.
• 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 coclasses : ce sont les classes instanciables. COM peut donc créer des
instances pour ces classes et les passer au client.
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.
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.
Ex :
Dim pLayer as ILayer
Set pLayer = New Featurelayer
pLayer.Name « couche d’entités »
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
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 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.
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.
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.
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 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 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.
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
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).
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.
Charger ensuite les bibliothèques ESRI requises pour le développement (aller dans
Projet>References).
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.
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.
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.
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.
Parmi les templates proposés, choisir Base command et appeler la nouvelle classe
ZoomsuruneCouche.vb.
N.B : le code ci-dessus suppose que le fichier bmp et la classe portent le même
nom.
L’extrait peut à tout moment être réduit en cliquant sur le signe « - » dans la
marge gauche.
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.
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.
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.
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.
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.
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
puis on instancie l’écouteur avec l’objet que l’on souhaite voir réagir aux
évènements
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 :
End Sub
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.
Sélectionner le map resource manager et clicker sur la flèche pour accéder au menu
contextuel. Editer les propriétés.
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.
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.
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 :
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.
function monUnloadHandler(event) {
dojo.disconnect(monclicconnect);
}
Code :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Create a Map</title>
<meta http-equiv="Content-Type" content="text/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");
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);
}
dojo.addOnLoad(init);
</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.
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>
<link rel="stylesheet" type="text/css"
href="http://serverapi.arcgisonline.com/jsapi/arcgis/1.4/js/dojo/dijit/themes/soria/soria.css"
>
<script type="text/javascript"
src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.4"></script>
<script type="text/javascript">
dojo.require("esri.map");
dojo.declare("pgwWMSLayer", esri.layers.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);
},
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());
}
dojo.addOnLoad(init);
</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 :
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().
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
"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,
"spatialReference": {
"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,
"spatialReference": {
"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() {
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’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.
Code :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html debug=true>
<head>
<meta http-equiv="Content-Type" content="text/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>
<script type="text/javascript">
var gmap = null;
var qtask = null;
var query = null;
var mapExtension = null;
var gOverlays = null;
function initialize() {
// création du fond Google Maps
gmap = new GMap2(document.getElementById('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 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>
</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.