Exploiter des données LIDAR dans ArcGIS

Si vous utilisez (où comptez utiliser) des données issues de la technologie LIDAR (Light Detection and Ranging), vous vous posez peut être des questions sur leur gestion et utilisation dans ArcGIS. Si c'est le cas, je vous recommande la lecture de la série d'articles qui vient de démarrer sur l'excellent blog "Geoprocessing Blog" rédigé par l'équipe Geoprocessing d'ESRI Inc.


Ci-dessous la liste des sujets qui vont être abordés parmi lesquels 3 ont été déjà été abordés:

• Assessing Lidar coverage and sample density
• Creating raster DEMs and DSMs from large Lidar point collections
• Data area delineation from Lidar points
• Using Lidar to estimate forest canopy density and height
• Creating intensity images from Lidar
• Updating a portion of a terrain dataset with new measurements
• Minimizing noise from Lidar for contouring and slope analysis
• Business partner solutions for Lidar
  

Bonne lecture !

Une application JavaScript en moins d'une heure !

En décembre dernier, ESRI mettait en ligne le "Flex Viewer Sample" pour permettre de construire très rapidement des applications Flex/Flash connectées à ArcGIS Server. Dans le même temps, le même projet a été mené pour l'API JavaScript par une équipe de développeurs d'ESRI Inc. et d'ESRI Canada. L'application est quasiment identique sur le plan fonctionnel et sur le plan de l'interface utilisateur. Le résultat est, de mon point de vu, tout à fait exceptionnel et démontre que des couples comme "JavaScript + Framework Dojo" permettent d'atteindre des niveaux d'IHM proches des autres technologies de RIA.

C'est quoi donc ?

Le "JavaScript Viewer Sample" est un modèle de site Web gratuit permettant de construire très rapidement une application web tirant partie des services web d'ArcGIS Server. Construit autour de l'API JavaScript d'ArcGIS Server, ce modèle d'application vous permet avec quelques lignes de paramétrage d'intégrer vos services de carte, d'imagerie, de géocodage, de géotraitements, de géométrie et d'extraction de données dans une interface web riche et sexy.

Les fonctionnalités proposées dans le modèle d'application sont les suivantes:

• Outils de navigation sur la carte
• Affichage d'un ou plusieurs services de fond de carte (généralement des services avec du cache)
• Affichage d'un ou plusieurs services de données métier (généralement des services dynamiques)
• Affichage d'une carte générale de localisation
• Affichage de points d'intérêt
• Outils de recherche et d'identification d'entités sur la carte
• Affichage de flux GeoRSS
• Affichage de données multimédias géolocalisées
• Outils de dessins permettant d'annoter la carte
• Outils de géocodage
• Gestion de Géosignets
• Exemple de fonction de calcul d'isochrone

Démarrer avec le "JavaScript Sample Viewer"

Le modèle se présente sous la forme d'un projet HTML/JavaScript (avec la totalité du code source) qu'il suffit de télécharger et d'ouvrir dans des outils comme Aptana Studio, Visual Studio ou encore Eclipse. La version originale (en anglais) est disponible sur le Resources Center de l'API JavaScript dans la Code Gallery. Une version française est disponible sur le site du support ESRI France. Dans cette version française, seule l'interface a été traduite. Les commentaires dans le code source et les services web utilisés dans le modèle original, ont été conservés. Vous pouvez également tester l'application en ligne à l'adresse suivante.

Un document de 44 pages explique comment est organisé le projet HTML/JavaScript et quels sont les fichiers de configuration à modifier pour personnaliser son application (les styles, les icones, les services, les textes de l'interface, la gestion du multi-langue, ...) :

Plus que ça …

Au delà d'être un modèle d'application, le "JavaScript Sample Viewer" est un framework de qui permettra aux développeurs de modifier les fonctions existantes ou d'étendre les fonctionnalités du modèle d'application en s'appuyant, notamment, sur la notion très intéressante de Widget. La documentation associée au modèle d'application présente les composants et l'architecture du projet HTML/JavaScript ainsi que les "design patterns" et "coding patterns" permettant un développement efficace sur ce framework proposé par l'équipe JavaScript d'ESRI.

A tous ceux qui ont des projets de RIA avec ArcGIS Server et qui se pose la question d'utiliser un framework JavaScript, je leur conseille vraiment de commencer par regarder de près ce modèle d'application compatible avec les explorateurs Firefox, Internet Explorer, Safari et Google Chrome.

Image Server, une technologie pour une diversité d'usages (2/2)

Je continue et termine aujourd'hui mon article consacré à la technologie Image Server. Comme je l'évoquais précédemment, la diversité des besoins et des sources de données d'imagerie à publier a conduit ESRI à proposer une solution évolutive permettant de répondre aux différents usages. Pour l'essentiel des besoins, deux options se distinguent. La première option consiste à utiliser les capacités de publication d'imagerie d'ArcGIS Server, la seconde option consiste à utiliser ArcGIS Server avec son extension ArcGIS Server Image.

Servir de l'imagerie pour un usage "donnée de fond de carte"

Si votre besoin est de publier de l'imagerie pour l'utiliser comme fond de carte (photo aérienne, MNT, Thermographie, …) et que cette dernière évolue peu souvent, la solution la plus simple et la plus performante est d'utiliser des services de cartes (Map Services) et de calculer des caches. Les applications bureautiques ArcGIS comme les applications web pourront alors consommer cette imagerie via des protocoles ESRI ou des protocoles normalisés comme WMS, WCS ou KML. Dans ce cas, le client accèdera à des images ce qui veut dire que la valeur des pixels correspondra simplement à des codes couleur.

Tous les formats de données raster supportés par ArcGIS peuvent être publiés en tant que Map Service, une licence ArcGIS Server (Standard ou Advanced) est nécessaire.

Servir de l'imagerie pour un usage "donnée raster"

Si votre besoin est de publier de l'imagerie pour l'utiliser comme source de donnée raster, c'est-à-dire exploiter la véritable valeur des pixels (altitude, radiométrie, …), la solution adéquate est d'utiliser des services d'imagerie (Image Services).

Un service d'imagerie permet de publier directement une source de données raster et de la rendre via le web à des applications web ou des applications bureautiques via des protocoles ESRI ou des protocoles normalisés comme WMS ou WCS. Dans ce cas, c'est la technologie Image Server d'ESRI qui est utilisée. Cette technologie permet une prise en charge de (très) gros volumes de données tout en restant dynamique. Ainsi, si une partie de mes données rasters est mise à jour, celle-ci est immédiatement visible par les consommateurs du service web. En utilisant un service d'imagerie, par opposition à un service de carte, l'utilisateur sera directement connecté à la donnée raster source. Ainsi, dans un produit comme ArcGIS Desktop, l'utilisateur pourra extraire en locale une partie des données.

Tous les formats de données raster supportés par ArcGIS peuvent être publiés en tant que service d'imagerie. Selon la complexité des besoins et l'organisation des sources de données, ArcGIS Server seul pourra couvrir les fonctionnalités attendues ou l'extension ArcGIS Server Image pourra être nécessaire.

Mon service d'imagerie est-il constituée d'une ou plusieurs source de données ?

Si vous avez une seule source de données telle qu'une mosaïque d'images dans une Géodatabase, un MNT, une grille d'interpolation ou d'analyse (Spatial Analyst ou Geostatistical Analyst par exemple), alors ArcGIS Server est capable de publier ce jeu de données en faisant simplement un clic-droit sur ce jeu de données puis en exécutant la commande "Publier vers ArcGIS Server". Dans cette configuration, les clients (ESRI ou non) accèdent au service d'imagerie via des protocoles basés sur HTTP (ESRI ou OGC WMS ou OGC WCS).

Si vous souhaitez servir une imagerie constituée de plusieurs sources de données telle qu'un catalogue d'images, une série temporelle d'images satellitaires, … alors vous devrez composer un fichier de définition de service d'imagerie (ISCDef) à l'aide de la barre ArcMap fournie par l'extension ArcGIS Server Image. Ce fichier contient la définition du service (gestion des bandes, gestion du mosaïquage, ré-échantillonnage, pyramidage, …) Une fois ce fichier ISCDef créé il peut être est publié en tant que service d'image par ArcGIS Server. Dans cette configuration, les clients (ESRI ou non) peuvent accèder aux services d'imagerie via des protocoles basés sur HTTP (ESRI ou OGC WMS ou OGC WCS). Ils peuvent également accéder aux services d'imagerie en RPC, pour les clients AutoCAD, MicroStation, MapInfo et Geomedia, un plug-in gratuit est fourni par ESRI.

Mon service d'imagerie doit-il réaliser des traitements à la volée ?

Lorsque vous publier un service d'imagerie avec l'extension ArcGIS Server Image, il est possible de spécifier que certains traitement pourront être réalisés à la volée par le serveur (automatiquement ou sur demande du client). Par exemple, le serveur pourra réaliser les traitements comme l'ortho-rectification de l'image, l'amélioration du rendu, la combinaison des bandes, des opérations d'algèbre d'image, du rehaussement panchromatique (pan-sharpening) ou encore des filtrages attributaires/spatiaux.

Conclusion

Nous avons rapidement parcouru les différentes options de publication de services d'imagerie avec ArcGIS Server. Pour aller plus loin, il y a comme d'habitude toutes les informations dans la documentation en ligne d'ArcGIS à la rubrique suivante.

Votre avis sur ArcGIS Explorer …

Afin d'envisager les évolutions futures d'ArcGIS Explorer, ESRI vous offre la possibilité de donner votre avis sur différents aspects de l'explorateur de services géographiques. Je vous encourage donc à y participer, il reste une semaine avant le bouclage de cette enquête.

Nous sommes à quelques semaines de la sortie de la prochaine version d'ArcGIS Explorer 900 qui sera une version majeure, totalement repensée en termes d'ergonomie et d'interface utilisateur. Nous aurons bien entendu l'occasion d'en parler le moment venu. En attendant, un aperçu très rapide vous est présenté dans la vidéo ci-dessous:

Image Server, une technologie pour une diversité d'usages (1/2)

Régulièrement, dans notre activité d'expertise technique, nous sommes sollicités pour définir la solution et l'architecture permettant de servir de manière adéquate de l'imagerie à différents utilisateurs d'une entreprise. La problématique est souvent complexe car qu'est ce qu'on entend par "servir" de l'imagerie ?

Même si certaines contraintes sont communes (large volume de données, mise à jour, performance d'accès), il y a généralement au sein de l'entreprise des besoins variables d'un utilisateur à un autre. Lorsque l'un consultera l'imagerie de manière en tant que simple "image" de fond de carte, l'autre aura besoin d'exploiter les valeurs des pixels de sa couche raster (altitude, radiométrie, valeur de concentration, …). Lorsqu'un utilisateur aura besoin de visualiser son image dans une application Web, l'autre utilisateur aura besoin de travailler localement sur l'image dans son application métier…

C'est en partant de ce constat, qu'ESRI a mis au point une technologie: Image Server. Cette technologie née en 9.2 et complètement finalisée en 9.3 se décline dans différentes configurations qui vont couvrir des besoins les plus simples aux besoins les avancés. L'objectif des mes deux articles est d'expliquer les trois configurations types pour la publication de services d'imagerie.

La technologie Image Server en quelques mots

Le premier point fort de la technologie Image Server c'est de pouvoir diffuser des services d'imagerie à partir de très larges volumes de données (plusieurs Tera-octets) sans avoir de conversion ou de prétraitement lourd à réaliser en amont. La procédure de mise en ligne et de mise à jour des sources de données est simplifiée et donc économique. Les fichiers sources restent dans leurs formats natifs, un mécanisme d'indexation spatial permet d'y accéder de manière très performante.

Le second point important c'est que le serveur d'imagerie Image Server peut réaliser des traitements à la volée, la encore sans avoir de préparation particulière à effectuer préalablement à la publication. Par exemple, le serveur va réaliser à la volée des opérations d'extraction, de ré-échantillonnage, de combinaison de bandes, de rectification géométrique, de changement de projection, de mosaïquage, … Cette capacité de traitement à la volée positionne, à elle seule, ArcGIS Image Server en tant que serveur d'imagerie et non en serveur cartographique (Web Mapping Server).

Avant de poursuivre et de détailler les différentes options offertes pour servir de l'imagerie avec la technologie Image Server, vous trouverez ci-dessous une vidéo d'une démonstration réalisée lors de SIG 2008. Cette présentation de mon collègue Jean-Thomas Rouzin illustre plusieurs aspects d'ArcGIS Image server à savoir :

• sa capacité à publier en quelques clics des services d'imagerie,
• sa capacité à fournir des services d'imagerie dynamique normalisés OGC (WMS, WCS),
• la consommation des services d'imagerie par un outil de traitement d'image non-ESRI (ici ENVI de la société ITT).

... la suite dans quelques jours.

Modélisation 3D avec ArcGIS

Il y a 10 ans, ESRI mettait au point le format de données Multipatch implémenté à l'époque dans les fichiers de formes (Shapefiles) devenant rapidement un standard dans le monde du SIG pour la représentation d'objets 3D. Depuis l'arrivée d'ArcGIS, la Géodatabase devient le réceptacle à prévilégier pour stocker les géométries Multipatch car elle offre en plus la possibilité d'associer à chaque face du Multipatch des textures donnant plus de réalisme à vos modèles 3D.

Les géométries Multipatch sont constituées de primitives 3D (triangles, bandes de triangles, triangles en élises, anneaux, …) combinés en une ou plusieurs parties pour constituer des entités 3D dans ArcGIS avec l'extension 3D Analyst. Depuis les toutes premières versions d'ArcGIS, les librairies ArcObjects permettent de générer ce type d'entités. Dans les versions plus récentes (9.2 et 9.3), des outils de Géotraitement permettent de transformer des données 2D en entités Multipatchs ou encore d'importer des fichiers 3D réalisés à l'aide d'outils de DAO. Par exemple, vous pouvez importer des fichiers 3D aux formats 3D Studio, VRML, GeoVRML 2.0, SketchUp 6.0 (ou via le plugin ArcGIS for SketchUp), OpenFlight ou encore COLLADA.

Les concepts liés aux géométries Multpatch ainsi que les différentes options permettant leur modélisation et leur intégration dans ArcGIS sont détaillées dans un nouveau White Paper (160 pages) sur le sujet. Si la modélisation de villes virtuelles vous intéresse, la lecture de ce document peut également constituer une introduction intéressante.

Lors de nos présentations de SIG 2008, plusieurs démonstrations nous avaient permis d'illustrer la maturité de la modélisation 3D dans ArcGIS et les intérêts que l'on peut avoir à gérer son modèle 3D dans un SIG. Une autre occasion de discuter avec nous de ces sujets est de venir nous voir sur le stand ESRI France au salon Imagina qui se déroule cette semaine (du 4 au 6 février) à Monaco. Mes collègues, certains de nos partenaires (comme Virtuel City) et encore des utilisateurs d'ArcGIS interviendrons sur le thème "Modéliser son territoire en 3D".

Premières lumières sur l'API Silverlight ArcGIS

C'est désormais officiel, ESRI vient d'annoncer la préparation d'une API Silverlight pour ArcGIS Server. Après l'API JavaScript et Flex, poursuivant la stratégie d'ouverture et d'interopérabilité d'ArcGIS Server, ESRI proposera d'ici quelques mois une option de développement supplémentaire pour la conception de RIA (Rich Internet Application).


Silverlight est la technologie de Microsoft permettant de développer des RIA (Rich Internet Application). Celle-ci est directement concurrente de Flex/Flash. En termes de fonctionnalités cette API devrait être très similaire aux API JavaScript et Flex puisqu'elle exploitera, de la même manière, les fonctionnalités de l'API Rest d'ArcGIS Server 9.3. La version actuelle : Silverlight 2.0 est la première version du plug-in qui va véritablement se répandre dans les navigateurs web et peut être venir prendre quelques parts de marché au plugin Flash.


Cliente de l'API REST d'ArcGIS Server dont elle exploitera la totalité des fonctionnalités, la logique et le positionnement de l'API Silverlight sera le même que les deux autres API (JavaScript et Flex). On y retrouvera donc l'ensemble des fonctionnalités permettant l'accès aux différents services d'ArcGIS Server (Cartes en cache, Cartes dynamiques, Imagerie, Géocodages, Calculs d'itinéraires/isochrones, Interrogation et extraction de données, Géotraitements, …).


Nous aurons l'occasion de reparler plus en détails de cette nouvelle API notamment à l'occasion du Developer Summit 2009. Après l'avoir expérimenté, je vous proposerais en particulier une comparaison entre ces 3 API. En attendant qu'ESRI propose une première version beta, une vidéo d'Art Haddad (ESRI's .NET Development Lead) est disponible ici.

Développer des Widgets pour le Flex Viewer Sample

En décembre dernier, je vous annonçais la disponibilité du Flex Viewer Sample, un exemple d'application générique et extensible basée sur l'API Flex d'ArcGIS Server et permettant de construire très rapidement des applications Flex connectées à votre serveur SIG. Au-delà de la qualité graphique de l'interface obtenue en grande partie grâce à la technologie Flash/Flex, l'objectif de cet exemple d'application est bien d'exploiter la richesse fonctionnelle d'ArcGIS Server. Ainsi, le Flex Viewer Sample a été conçu pour être étendu notamment par le développement de Widgets.

Notion de Widget

Un Widget est un module fonctionnel configurable et facilement réutilisable dans différentes applications (basées sur le Flex Viewer Sample).

Exemple de Widget permettant de paramétrer une carte thématique

En tant que développeur, créer un Widget est quelque chose de simple puisqu'il s'agira de dériver la classe de base prenant en charge les comportements communs à tous les Widgets (affichage, effets, configuration, …). L'intérêt c'est que le développeur peut se concentrer sur le codage des fonctionnalités sans se soucier de la gestion de l'affichage déjà prise en charge dans le noyau de base du Flex Viewer Sample.

Le schéma ci-dessous décrit les différentes étapes de création d'un Widget:



1- Ecrire un module Flex en étendant la classe "Base Widget".
2- Ecrire le code permettant l'accès aux cartes, données et services.
3- Ajouter la référence au Widget dans le fichier Config.xml de l'application.

A- Le Widget Manager gère le cycle de vie de votre Widget en fonction des informations stockées dans le fichier Config.xml.
B- Le noyau de l'application Flex Viewer Sample communique avec votre Widget via les interfaces implémentées par votre Widget.

La notion de Widget est donc le moyen le plus adapté pour étendre le Flex Viewer Sample. Des exemples de Widgets sont régulièrement publiés sur le Code Gallery de l'API Flex systématiquement avec les codes sources. Je tâcherais donc de signaler sur ce blog les plus intéressants d'entre eux.