Le blog francophone consacré
aux technologies Esri

SIG 2017 - Retour sur ma démo CityDashboard

ArcGIS est une plateforme Web SIG, ce qui veut dire que son architecture intègre, à différents niveaux, les paradigmes du web (technologies, architectures, standards et protocoles). Cette approche a permis aux SIG de s'adresser à une palette plus large d'utilisateurs. En particulier, le SIG accède désormais à une multitude de nouvelles sources de données, via des APIs et des services web, fournissant des informations en temps-réel (capteurs, réseaux sociaux, objets connectés,...).


Lors de la session plénière de la conférence SIG 2017, j'ai eu l'occasion de présenter une application web nommée CityDashboard, démontrant notamment ces capacités. Avec cette application, je souhaitais montrer, à travers un exemple concret sur Paris, la création d'interface modernes et efficaces (avec l'API JavaScript 4.x d'ArcGIS), le streaming d'importants volumes de données 3D sur le web (avec un portail ArcGIS) ainsi que l'intégration et la diffusion de flux de données temps-réel (avec ArcGIS Enterprise et son composant GeoEvent Server).
  

Démo CityDashboard lors de SIG 2017

Je vous propose de prendre un peu plus de temps que dans ma démo de SIG 2017 pour détailler les principaux aspects de cette application.


Les données 3D utilisées

L'API JavaScript 4.x d'ArcGIS permet de travailler avec des scènes web. Celles-ci sont l'équivalent des cartes web mais dans un environnement 3D. Une scène web peut contenir:

  • des couches de fonds de carte (tuiles raster ou tuiles vectorielles, comme en 2D),
  • des couches d'élévation (MNT raster),
  • des couches d'entités (2D ou 3D),
  • des couches de scènes (Objets 3D, Mesh 3D, Nuages de points ou points 3D).

Les couches de scènes sont des couches 3D optimisées pour un streaming web efficace à n'importe quelle échelle grâce au standard OGS i3S. C'est par exemple ce type de couche que j'ai utilisé pour les 572000 bâtiments 3D de la scène. Ces couches de scènes ont été publiées à partir d'ArcGIS Pro sur un portail ArcGIS Enterprise (ArcGIS Online était également un choix possible) à partir de classes d'entités Multipatch d'une Géodatabase Fichier.

Afin de tester et d'illustrer plusieurs processus de génération de modèles 3D, différentes sources de données et méthodes ont été utilisées pour obtenir ces bâtiments.

L'essentiel des multipatch des bâtiments ont été générés à partir de polygones d'emprises et de règles procédurales CityEngine (données Open Data de l'APUR).


Certains arrondissements (1,2,3,4,9,11,...) ont été couverts par des modèles 3D (en LOD 2,5) fournis en Géodatabase par la société CyberCity 3D.


Enfin, une trentaine de bâtiments remarquables ont été intégrés en multipatch à partir de modèles 3D individuels (sketchup, kml, ...).


  
Les flux de données temps-réel utilisés

L'avantage de choisir Paris comme terrain de jeu pour une telle application, c'est de disposer de nombreuses APIs et services web de données temps réel. L'idée était d'en choisir quelques-unes provenant d'origines variées et traitant des thèmes diverses. Les APIs suivantes ont donc été intégrées:


 
Collecte et diffusion des flux de données




Deux approches sont généralement envisageables pour intégrer des flux de données dynamiques issus d'APIs Web. Ces approches dépendent de la fréquence d'actualisation des données fournies par l'API.

Approche "Temps-réel"

Si la fréquence d'actualisation est très élevée, l'API propose généralement des modes de connexion "persistante" tels que les WebSockets. Dans ce cas, des composants comme ArcGIS GeoEvent Server sont tout à fait adapté à la réception des différents messages temps-réel, à leur traitement et à leur rediffusion sous différentes formes (nouveau message temps-réel, mises à jour ou ajout dans une couche ou table, écriture de logs, envoie de sms/email/...). Cependant, au regard des APIs utilisées dans mon cas, hormis l'API Twitter, aucune ne justifiait une telle approche puisque les fréquences d'actualisation sont de l'ordre de quelques minutes à quelques heures.

Approche "par requête"

Lorsque la fréquence d'actualisation est moins élevée, les APIs peuvent être interrogées de manière régulière et les informations peuvent être mise à disposition de l'application cliente directement ou par l'intermédiaire d'un fichier ou d'une base de données intermédiaire.
  
Dans mon cas, cela pouvait alors se faire de 2 manières.

Une première possibilité consiste à utilise le composant GeoEvent d'ArcGIS Enterprise pour envoyer, à intervalles réguliers (par exemple toutes les minutes), des requêtes Http/Rest vers les différentes APIS afin de traiter le message JSON reçu et le diffuser en tant que service de flux ArcGIS (Stream Services) ou en ajoutant/modifiant les entités d'un service d'entités ArcGIS (Feature Service). L'application CityDashboard peut ensuite afficher le service de flux ou le service d'entités.
  

Une seconde possibilité consiste à ne pas utiliser le composant GeoEvent et le remplacer par des scripts (Python) qui se chargent, à intervalles réguliers (par exemple toutes les minutes), d'envoyer des requêtes Http/Rest et de traiter les réponses JSON pour les mettre dans des fichiers normalisés (JSON Esri, GeoJSON ou autre). L'application CityDashboard peut ensuite requêter ces fichiers et afficher les entités dans la scène 3D. Cette approche ne nécessite aucun composant Esri sur le serveur mais, contrairement à la première, nécessite du développement. Pour des raisons de portabilité de la partie serveur de la démo, c'est l'option que j'ai choisie. 

  
  
Développement de l'application

L'application n'est pas issue d'un modèle d'application ArcGIS. Il s'agit d'un développement personnalisé réalisé à l'aide de l'API ArcGIS for JavaScript 4.5. L'application construit la scène 3D et ajoute les couches de scènes depuis un portail ArcGIS à la volée lors du démarrage de l'application. Aucun plug-in n'est nécessaire puisque l'API JavaScript d'ArcGIS exploite les capacités WebGL du navigateur.

Le mécanisme de bandeau et de fiches animées est un développement spécifique exploitant la notion de Widget du framework Dijit (Dojo).

On notera également l'intégration de la librairie 3D Three.js qui permet d'afficher le cercle animé autour du point correspondant à la fiche courante. Pour plus d'informations sur l'intégration de librairie externes dans les scènes 3D ArcGIS, vous pouvez vous reporter à cette page de la documentation de l'API ArcGIS for ArcGIS.

L'application CityDashboard est accessible depuis cette URL. N'hésitez pas à me faire part de vos question complémentaires via les commentaires...



Partager cet article:

Rejoindre la discussion

    Les commentaires à propos de cet article:

2 commentaires :

x. lhomme a dit…

Bonjour
Est-il possible de récupérer le script python Robots ? Si oui sous quelle forme Github, Contrat ESRI France, ...
Cordialement

Gaëtan Lavenu a dit…

Bonjour Xavier,

Les scripts Python évoqués dans mon article et utilisés pour cette démo sont disponibles via le lien ci-dessous. Cependant, j'attire ton attention sur les points suivants:
- la structure des fichiers JSON peu varier selon la thématique
- il s'agit de scripts de démo, c'est à dire non-commentés et testés uniquement dans le contexte de la démo.

Téléchargement:
https://drive.google.com/open?id=1foanVRPslh9OZRpYn9goT10z8UtB1_Me