Le blog francophone consacré
aux technologies Esri

La version 4.14 de l'API JavaScript ArcGIS est disponible

Depuis aujourd'hui, la dernière mise à jour de l'année de l'API JavaScript ArcGIS est en ligne. Elle intègre de nombreuses améliorations dont vous allez pouvoir tirer profit dans le développement de vos applications web. Certaines de ces évolutions concernent le support du clustering sur les couches de points 2D, la possibilité d'enregistrer/modifier des cartes web, l'ajout de nouveaux outils d'analyse 3D coté client, l'arrivée d'un widget permettant de régler l'éclairage et l'ombrage d'une scène à partir de la date/heure, l'ajout de nouvelles options sur le curseur temporel de vos cartes, ou encore des améliorations de performances significatives en 2D et en 3D. Je vous propose de faire le tour des évolutions les plus notables.
   

   
Support du clustering (en beta)

Comme l'API 3.x, l'API 4.x prend désormais en charge le regroupement dynamique des couches d'entités de points côté client. Ceci est accessible également pour les couches GeoJSON et les couches CSV dans vos cartes 2D. Vous pouvez décider comment chaque cluster regroupe les données sous-jacentes. Vous pouvez utiliser un seul symbole de cluster à dimensionner en fonction du nombre d'entités au sein du cluster, ou de lui appliquer un rendu exprimant la synthèse des valeurs des entités regroupées au sein du cluster. Dans ce deuxième cas, vous pourrez soit représenter les valeurs moyennes ou prédominantes des entités de chaque cluster ou représenter la valeur la plus courante au sein d'un cluster. Les fenêtres contextuelles peuvent également être configurées pour afficher des informations récapitulatives pour le cluster.


Certaines capacités de clustering de l'API 4.x vont plus loin que ce qui est possible en 3.x, parce qu'il s'appuie sur des capacités qui font déjà partie de la version 4.x. Par exemple:

  • Le clustering en 4.x permet de charger et de restituer de très grands volumes de données avec des performances optimisées, grâce à WebGL et à l'intelligence des mécanismes de requête et d'affichage des couches d'entités. Alors que 3.x avait une limitation de mise en cluster d'un maximum de 50 000 entités, la version 4.x n'a pas une telle limite.
       
  • Lorsque vous effectuez un filtrage côté client sur les entités d'une couche, les clusters sont automatiquement recalculés côté client. Les clusters affichent uniquement des informations conformes au filtre, notamment le nombre d'entités et la catégorie prédominante (voir cet exemple).
       
  • Les couches GeoJSON constituent une source de données de premier choix avec l'API 4.x. Ainsi, tout comme vous pouvez exploiter les rendus de smart-mapping, effectuer des requêtes côté client, filtrer et calculer des statistiques, etc... vous pouvez donc activer le clustering de la même manière que vous le feriez avec une couche d'entités ArcGIS (voir cet exemple).
Comme avec la version 3.x, les options de clustering peuvent être définies directement dans votre code ou configurées dans une carte web sur votre portail ArcGIS Online ou Enterprise, puis simplement chargées dans votre application. Ce n'est que la version initiale du clustering; des travaux sont déjà en cours pour étendre la flexibilité et la puissance du clustering, notamment avec le clustering côté serveur pour d'énormes ensembles de données ou encore la possibilité d'étiqueter les clusters avec le nombre d'entités sous-jacentes.
   
    
Enregistrer des cartes Web

La carte web est le medium incontournable du système ArcGIS. En tant que développeur, il est peut être très intéressant de permettre aux utilisateurs de votre application de modifier leur carte (étendue, couches, visibilités, rendus, ...) et de pouvoir l'enregistrer dans leurs contenus pour exploiter L'enregistrement de cartes web est désormais possible avec quelques lignes de code. Vous pourrez ainsi permettre aux utilisateurs de votre application de mettre à jour une carte web existante ou d'en créer une nouvelle et l'enregistrer sur leur portail ArcGIS Online (ou ArcGIS Enterprise). Il s'agit d'une fonctionnalité très simple mais puissante qui vous permettra de créer des applications encore plus étroitement intégrées à l'écosystème géospatiale de votre organisation.
  
   
  
Comparer facilement des jeux de données décalés dans le temps

Des améliorations ont été apportées aux capacités de l'API pour la visualisation de données temporelles. Il est dorénavant possible de définir un "décalage" temporel sur une couche d'entités pour pouvoir la ramener à la même plage temporelle que d'autres couches afin de pouvoir les comparer. Par exemple, vous souhaitez comparer les accidents sur l'année 2009 et l'année 2019 mois par mois. Il suffira de définir un décalage de 10 ans sur la couche d'entités de 2009 pour déplacer virtuellement les données sur 2019 et pouvoir ainsi les comparer. Ensuite, en utilisant le widget "TimeSlider", l'utilisateur pourra ajuster interactivement l'étendue temporelle pour comparer les données des deux années, de mois en mois ou tout autre pas de temps souhaité (voir cet exemple).

  
  
Mise à jour des pièces jointes et nouvelles options
   
La prise en charge des opérations de mise à jour a été introduite dans l'API 4.x de manière itérative sur plusieurs versions. Avec la version 4.14, vous pouvez désormais ajouter, mettre à jour et supprimer des pièces jointes grâce à la méthode FeatureLayer.applyEdits(). Dans le futur, cette capacité sera également disponible via les widgets de mise à jour de l'API. Plus d'options ont également été ajoutées sur la méthode applyEdits afin de contrôler la façon dont les modifications doivent être traitées selon les workflows de mise à jour. Par exemple, pour spécifier la version de la géodatabase cible des modifications (pour les bases de données versionnées) et encore pour les modifications qui doivent être appliquées uniquement si toutes les modifications soumises sont valides.
    
    
Widget de ligne de visibilité

Un nouveau widget "Line of Sight" permet désormais aux utilisateurs de votre application d'analyser interactivement des lignes visibilité dans les scènes 3D. En plaçant deux points (ou plus) sur des bâtiments, sur le sol ou d'autres objets de la scène, ils pourront évaluer la visibilité directe entre les différents points de chaque ligne de visibilité. Par exemple, vous souhaiterez peut-être évaluer l'impact d'une construction planifiée par rapport aux bâtiments environnants. Les résultats de l'analyse se mettent à jour de manière interactive lorsque vous déplacez l'observateur ou les cibles dans votre scène. En plus de permettre à l'utilisateur final d'effectuer l'analyse de manière interactive, vous pouvez définir dans votre code JavaScript l'observateur et les cibles pour l'analyse (voir cet exemple).
   
   
    
Widget d'éclairage et d'ombrage ambiant

Un nouveau widget "Daylight" vous permettra de définir les paramètres de date et heure pour simules les conditions d'ombre et d'éclairage ambiant. L'utilisateur pourra modifier l'heure et la date pour voir les ombres projetées par les objets 3D dans votre scène. Le widget vous permet également d'animer la lumière du soleil tout au long de la journée, et inclut même des étoiles dans le ciel à leur emplacement correct. Ce widget est alimenté en utilisant des informations d'éclairage précises pour n'importe quelle condition: année, jour, heure et lieu sur terre (voir cet exemple).

   
   
Étiquettes pour les couches de scènes d'objets 3D

Les couches de scène contenant des objets 3D tels que des bâtiments, des équipements urbains, ... prennent désormais en charge les étiquettes. Ainsi, vous pourrez disposer des mêmes capacités d'étiquetage que les couches d'entités. Votre code JavaScript pour l'étiquetage des objets 3D sera d'autant plus simplifié que vous pourrez générer des étiquettes directement à partir des attributs du cache de votre SceneLayer au lieu d'utiliser la couche d'entités associée.
   
   
      
Amélioration des performances

L'API est améliorée en permanence pour augmenter les performances. Parmi ces améliorations on notera les points suivants:
  • Amélioration significative des performances de la GPU en réduisant le nombre de sommets des polygones dessinés, tout en conservant la même qualité visuelle de la forme du polygone.
  • Lors du rendu des tuiles vectorielles, le nombre d'appels WebGL a été réduit de 20 à 25% et beaucoup moins d'appels JavaScript sont effectués. Ceci se traduit par une expérience et une interaction plus fluide.
  • Le rendu a été optimisé pour les photomaillages 3D (3D Textured Mesh).
  • Le rendu des objets "Graphic" est également plus rapide lorsqu'ils sont ajoutés à la collection "Graphics" ou "GraphicsLayer", ou lorsqu'elles sont ajoutées aux collections d'entités via l'instruction FeatureLayer.source, car l'API ne simplifie plus les géométries. Il est de la responsabilité du développeur de vérifier l'exactitude des géométries de polygone avant qu'elles ne soient ajoutées à ces couches.

  
  
Modernisation de l'API

A chaque version, l'API se modernise et se simplifie. Les navigateurs modernes offrant un nombre croissant de fonctionnalités, ils peuvent en faire plus avec moins de code JavaScript ce qui est également vrai pour l'API qui devient donc plus puissante et plus légère. En 4.14, l'équipe de l'API se s'est concentrée sur les points suivants:
  • Les "promises" jouent un rôle important dans l'API car elles permettent d'écrire un code plus propre lorsque vous travaillez avec des opérations asynchrones. Auparavant, elles étaient mises en œuvre à l'aide des "promises" de Dojo. Dans la version 4.12, Esri a introduit l'option d'activation des "promises" natives JavaScript. Il est prévu de faire en sorte que l'API exploite les "promises" natives de JavaScript par défaut en 4.15, puis de supprimer complètement les "promises" Dojo en 4.16. Plus de détails sur cette fonctionnalité seront disponibles prochainement dans un article sur le blog ArcGIS.
  • Esri travaille sur la suppression de la dépendance au module de déclaration de Dojo (et sur la suppression éventuelle de la dépendance de l'API à Dojo). Ce travail implique la migration de l'implémentation de certaines classes de l'API pour tirer parti du système de classes JavaScript pur (et TypeScript) et ne plus reposer sur l'utilisation de "Dojo declare". La première étape de cette migration consiste à adopter les Mixins avec TypeScript et JavaScript par opposition à l'héritage multiple. Bien que l'héritage multiple soit toujours pris en charge dans les applications construites avec l'API, il est obsolète depuis la version 4.13 et vous demandera éventuellement de modifier votre code (si vous utilisez ce modèle). Un message d'avertissement s'affiche dans la console du navigateur pour vous rappeler ce changement.
  
  
Guide sur les meilleures pratiques de sélection des couleurs
  
Plusieurs centaines de dégradés de couleurs sont proposés dans l'API pour le rendu des couches (Smart Mapping). Ils peuvent désormais être facilement visualisées, filtrées et copiées dans vos applications à partir de cette page de la documentation.

   
     
Pour en savoir plus...

Il y a bien d'autres évolutions dans cette version, par exemple une option pour désactiver le zoom avec la molette de la souris et le panoramique avec un seul doigt (utile pour les appareils tactiles), des mises à jour dans les capacités de Smart Mapping, y compris la possibilité de contrôler la taille des symboles en fonction de l'échelle de la carte, et plus de 50 corrections de bugs. Pour en savoir plus sur cette version 4.14, explorez:

Partager cet article:

Rejoindre la discussion

    Les commentaires à propos de cet article: