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).
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:
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, ...).
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, ...).
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:
- Infos de trafic, accidents et travaux de l'API Waze (Waze Connected Citizen Program)
- Flux des caméra de vidéo-surveillance (APRR/AREA et autres)
- Flux de données sur les stations Vélib (API JCDecaux)
- Flux de données Autolib (API Autolib)
- Flux des événements culturels (API OpenAgenda)
- Flux des publications Twitter (API Twitter Streaming)
- Flux de données des stations météo NetAtmo (API NetAtmo Weather)
Collecte et diffusion des flux de données
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 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...
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...
Note du 02/09/2018:
A noter que plusieurs services web utilisés par cette application ne sont plus disponibles. Une nouvelle application très similaire et plus complète est désormais disponible sur la métropole du Grand-Lyon.
A noter que plusieurs services web utilisés par cette application ne sont plus disponibles. Une nouvelle application très similaire et plus complète est désormais disponible sur la métropole du Grand-Lyon.