Découvrez la version 300.0 des SDKs d'ArcGIS pour applications natives

La version 300.0 des ArcGIS Maps SDKs for Native Apps constitue une étape majeure, introduisant des fonctionnalités importantes, dont certaines totalement inédites pour les SDK mobiles, ouvrant la voie à une nouvelle catégorie d’applications SIG.  Avec le passage de la version 200.8 à 300.0, l’accent est mis sur l’extension des capacités, avec trois nouveautés majeures : les scènes locales, les couches de scène de bâtiment et un tout nouvel ensemble d’outils d’analyse spatiale.

Scènes locales

Les SDKs pour applications natives prennent en charge la 3D depuis la version 100.0, il y a environ dix ans, mais toujours dans un contexte global. Cela implique l’utilisation du système de coordonnées géographiques WGS84 pour l’affichage des données, et pour des performances optimales, ces données doivent généralement être publiées en WGS84 afin d’éviter une reprojection à la volée. Cette reprojection consomme des ressources CPU, ce qui peut entraîner une consommation accrue de batterie sur les appareils mobiles. Publier une copie distincte des données en WGS84 permet de contourner ce problème, mais introduit souvent une surcharge inutile.

 

Cette nouvelle version introduit le local scene view. Il s’agit d’un tout nouveau composant d’interface que l’on peut intégrer à une application, permettant de travailler avec une scène locale, qu’elle provienne d’une scène web, d’un scene package mobile embarqué sur un appareil ou qu’elle soit créée via le code de l'application. Une scène locale peut utiliser n’importe quel système de coordonnées projeté, en adéquation avec vos données publiées..
 

La vue de scène locale a été conçue de bout en bout pour exploiter au mieux les pipelines GPU modernes, ce qui apporte plusieurs avantages clés :

• Les performances ont été optimisée en séparant la gestion des données de leur rendu, permettant aux CPU et aux GPU de se concentrer sur leurs tâches respectives, réduisant ainsi la charge globale et la consommation de batterie. 
• Cela permet également une gestion plus efficace de la mémoire, avec une meilleure capacité à gérer scènes complexes et aux situations de pression mémoire. Par exemple, il devient possible de distinguer une pression mémoire liée à la complexité des données d’une pression liée à leur volume, et d’y répondre différemment.
• Le nouveau pipeline exploite les optimisations intrinsèques aux données 3D, comme les symboles incluant plusieurs niveaux de détail (multi-LOD), afin d’afficher le meilleur niveau de fidélité en fonction de l’appareil, de la scène et du point de vue. 
• Enfin, il permet de prendre en charge des rendus physiquement réalistes glTF (PBR), incluant matériaux, émissions lumineuses, occlusion ambiante et autres effets, pour valoriser visuellement les données.

L’ensemble de ces améliorations se traduit par de meilleures performances, une qualité visuelle accrue et une autonomie optimisée sur les appareils mobiles.

Nouvelles APIs pour les scènes

Plusieurs nouvelles API accompagnent la local scene view, supportant des capacités définies dans la spécification des scènes web :

• Les scènes disposent désormais d’une propriété décrivant le mode d’affichage, local ou global. Cette information peut être lue depuis une scène web ou mobile, ou définie lors de la construction de la scène via le code. En l’absence de définition explicite, le mode global est utilisé par défaut, garantissant la compatibilité avec le code existant en version 200.x.
• Le contrôle du rendu de l’environnement est désormais défini directement au niveau de la scène.
• Les scènes locales permettent de définir une zone de découpage afin de restreindre l’expérience à une zone d’intérêt spécifique.

De nouveaux événements signalent également les incohérences entre types de scènes et de vues, ou les situations de pression mémoire dans la vue locale.

En tant que nouveau composant, certaines fonctionnalités ne sont pas encore disponibles dans les scènes locales. Cette première version est centrée sur les contenus 3D et ne prend pas encore en charge les couches d'entités ni les couches graphiques. Ces limitations et leur feuille de route sont détaillées dans la documentation des SDKs .NET, Flutter, Kotlin, Qt et Swift.

Cette expérience de scène locale repose sur les mêmes pipelines que ceux utilisés par les SDK ArcGIS pour Unity et Unreal Engine depuis 2022.  

Couches de scènes de bâtiment

Les couches de scène de bâtiment sont un type de couche 3D, essentiels pour les workflows AEC. Ellesl permettent de représenter des modèles BIM complexes avec un niveau de détail fin et des performances élevées. Ces couches sont désormais supportées pour la première fois dans les SDKs natifs via la nouvelle expérience de scène locale. Au-delà de leur qualité visuelle, les couches de scène de bâtiment permettent d’explorer en profondeur les composants individuels des modèles de bâtiments, tant visuellement que via des APIs donnant accès aux données sous-jacentes.

Les modes X-Ray et Wireframe permettent d’examiner facilement l’intérieur des modèles. Il est également possible de contrôler précisément les couches affichées, jusqu’au niveau des entités. Les objets peuvent être sélectionnés et identifiés pour consulter leurs attributs et afficher des infobulles. Les rendus de chaque sous-couche peuvent être modifiés dynamiquement afin de mettre en valeur certains éléments. Si les modèles intègrent des capacités glTF PBR, celles-ci sont restituées avec précision, en tenant compte notamment des ombres et de l’heure de la journée.

Les API offrent un contrôle complet sur l’expérience, qu’il s’agisse de masquer des murs, d’afficher uniquement les réseaux électriques ou de se concentrer sur un étage spécifique. 

En complément, Esri propose un nouveau toolkit  permettant d’explorer les building couches de scène en détail, avec un contrôle sur les étages et les sous-couches. Disponible initialement pour Flutter et Swift, il sera étendu à d’autres SDK dans les prochaines versions. 

Outils d’analyse spatiale

Le troisième pilier de la version 300.0 est un nouvel ensemble d’outils d’analyse spatiale. Conçus pour fonctionner directement sur les données à pleine résolution, ces outils offrent des performances très élevées et produisent des résultats exploitables pour la prise de décision, le stockage local ou l’affichage. Leur rapidité permet même des usages interactifs.

Ces outils sont compatibles avec l’ensemble des plateformes cibles des Native Maps SDKs, des ordinateurs aux smartphones. Disposer de capacités analytiques aussi précises et performantes sur des appareils mobiles ouvre des perspectives inédites pour le développement d’applications.

La première version inclut notamment l’analyse de visibilité (viewshed et ligne de visée), une API d’algèbre cartographique puissante et flexible, ainsi qu’un overlay d’analyse pour les workflows interactifs.

Analyse embarquée dans les SDKs natifs

Historiquement, les SDKs natifs proposaient déjà des capacités d’analyse locale hors ligne, réparties en quatre grandes catégories : 

• Analyse sur jeux de données : géocodage, analyse de réseau, analyse sur des utility network ;
• analyse géométrique : comparaison, manipulation, reprojection géographiques de lignes, points et polygones en se basant sur le geometry engine ;
• analyse visuelle 3D exploratoire ;
• Local server.

Pour des analyses spatiales précises, deux approches étaient possibles : le geometry engine pour des géométries simples, ou le Local Server pour des analyses plus complexes impliquant des jeux de données complets et des logiques personnalisées, au prix d’une dépendance à des environnements spécifiques (Windows ou Linux) et à la nécessité de maintenir le Local Server en plus de votre application.

Les analyses visuelles 3D permettaient des calculs rapides via le GPU, garantissant de très bonnes performances mais restant limitées aux données visibles à l’écran, avec une précision dépendante du rendu et sans production de résultats exploitables.

La version 300.0 introduit une cinquième catégorie, combinant précision et performance. Les nouveaux outils travaillent sur les données sources à pleine résolution et s’appuient sur un pipeline GPU dédié, distinct de celui du rendu. Les résultats produits sont précis et peuvent être affichés, analysés, interrogés ou enregistrés. 

 

Exploration des nouvelles APIs d’analyse

Le principe d’utilisation est simple : charger des données, définir une séquence d’opérations d’analyse, puis exécuter l’analyse ou l’afficher via un overlay.

Les opérations peuvent être des analyses de visibilité (champ de vision et ligne de visée), des opérateurs d’algèbre cartographique, ou une combinaison des deux. 

 

L'extrait de code ci-dessous se base sur l'API algébrique dans le SDK Swift pour classifier les données d'élévation en 4  catégories et les afficher sur la carte dans des couleurs différentes. 

A mesure que l’on construit une analyse en combinant différentes opérations, les APIs préparent un pipeline de calcul GPU optimisé à partir de ces opérations. Point essentiel, ce pipeline n’est pas exécuté tant que le résultat n’est pas explicitement demandé. D’un point de vue technique, Esri combine ici une lazy evalution avec une fusion des opérations appliquées à la chaîne d’analyse. Cette approche permet aux APIs d’optimiser les traitements en regroupant les opérations avant leur exécution, ce qui réduit à la fois le temps de calcul et l’utilisation de la mémoire en évitant de produire ou de stocker des résultats intermédiaires.

L’un des aspects les plus intéressants de cette approche est la possibilité de modifier simplement les paramètres utilisés à n’importe quel niveau de la chaîne d’opérations, avec un impact immédiat sur le pipeline optimisé. Par exemple, si l’observateur d’une analyse de ligne de visée se déplace, il suffit de mettre à jour sa position telle qu’elle a été définie dans l’analyse, et le prochain calcul reflétera automatiquement cette nouvelle localisation. Si un overlay d’analyse est utilisé pour afficher les résultats sur une carte, son rendu se mettra à jour instantanément dès que la nouvelle position est fournie. Dans l'exemple ci-dessous, plusieurs analyses de ligne de visée sont configurées à partir d’un seul observateur. En modifiant la position de cet observateur, l’ensemble des analyses est mis à jour, et ce de manière extrêmement rapide.

Licence des APIs d'analyse 

Afin d’aligner ces nouvelles capacités d’analyse des Native Maps SDKs avec celles de Local Server et d’ArcGIS Pro, les API de visibilité et de ligne de visée sont proposées avec un niveau de licence Standard, tandis que les opérations d’algèbre cartographique nécessitent l’extension Analysis. L’ensemble des API reste accessible gratuitement en mode développeur. 

Évolutions prévues pour l'analyse

Ces nouvelles capacités marquent le début d’une évolution plus large. D’autres outils sont déjà en préparation, à commencer par le calcul de pente, d’exposition et la conversion raster vers polygone. Les priorités de développement sont définies en fonction des retours des utilisateurs, notamment pour accompagner les développeurs dans la migration de leurs applications depuis Local Server et ArcGIS Engine. De nouvelles fonctionnalités d’analyse seront introduites à chaque version.

Évolutions des licences

La version 300.0 introduit également un changement important concernant l’utilisation des chaînes de licence pour un usage en production.

Pour rappel, deux modes de licence existent pour les applications basées sur les Native Maps SDKs : le mode utilisateur nommé, dans lequel l’utilisateur final se connecte à un compte ArcGIS Online ou ArcGIS Enterprise, et le mode par licence string (chaîne de licence), dans lequel le développeur intègre une chaîne de caractères fixe dans l’application.

Dans le cas des utilisateurs nommés, aucun changement n’est à signaler. En revanche, l’utilisation des chaînes de licence évolue. À partir de la version 300.0, celles-ci sont désormais liées à une version majeure. Une chaîne de licence 100.x reste valable pour les versions 100.x et 200.x, mais une nouvelle chaîne 300.x est nécessaire pour utiliser les SDK en version 300.x.

Pour les licences Lite gratuites, il suffit d’obtenir une nouvelle chaîne 300.x depuis My Esri, accessible via la carte « ArcGIS Maps SDKs for Native Apps License Strings » sur la page d’accueil du tableau de bord.

Si un message indique que le compte ArcGIS organisationnel n’est pas autorisé à accéder aux sites esri.com, il est nécessaire de contacter l’administrateur de l’organisation afin d’activer cet accès ou de définir un mode de distribution des chaînes de licence Lite.

Pour les licences Basic, Standard, Advanced ou les extensions, de nouvelles chaînes 300.x doivent être obtenues avant de déployer des applications avec les SDK 300.x. Celles-ci sont fournies sans coût supplémentaire pour les clients disposant d’un contrat de maintenance actif. Dans le cas contraire, il convient de se rapprocher du gestionnaire de compte ou du service client Esri. 

Les autres nouveautés de la 300.x

Si les scènes locales, les couches de scène de bâtiment et les nouveaux outils d’analyse spatiale constituent les principales nouveautés de la version 300.0, de nombreuses autres nouveautés ont également été apportées :

• Un domaine notable concerne la prise en charge des courbes vraies. En version 300.0, celles-ci sont désormais disponibles hors ligne par défaut, affichables en 3D, et bénéficient d’un premier niveau de support dans l'éditeur de géométries.
  
• Le support des rasters a également été renforcé, avec de nouvelles capacités de colorisation, une meilleure gestion de l’interpolation selon les usages, et un accès étendu aux métadonnées permettant d’afficher les données à l’échelle la plus pertinente.
• La prise en charge des templates partagés a été ajoutée, avec la lecture et l’utilisation de feature templates, preset templates et group templates depuis des feature services et des géodatabases. Ces templates sont couramment utilisés dans les utility networks, mais trouvent leur place dans de nombreux workflows de création de données. Les preset templates permettent de positionner plusieurs entités selon un motif prédéfini autour d’un point, tandis que les group templates appliquent des règles de construction complexes à partir d’une géométrie de base. Les feature templates permettent quant à eux de créer automatiquement des enregistrements liés lors de la création d’une entité.
• La gestion des associations dans les utility networks via les formulaires d’entités s'enrichit avec des fonctionnalités intégrées de création, modification et suppression.
• Les API de navigation prennent désormais en charge les itinéraires piétons. Le composant RouteTracker adapte son comportement en conséquence, notamment pour la détection d’arrivée, le calcul des temps de parcours en fonction de la vitesse de marche, le déclenchement des événements liés aux manœuvres à venir, ou encore la prise en compte des demi-tours en tout point de l’itinéraire.

La version 300.0 inclut également d’autres améliorations ainsi que de nombreuses optimisations de performance et corrections, parmi lesquelles : 

• Un meilleur support des tuiles 3D photoréalistes Google ;
• La gestion de pièces jointes volumineuses jusqu’à 1 Go dans les formulaires d’entités ; 
• L’interrogation d’entités dynamiques par identifiant de trace ;
• La modification de la référence spatiale d’une carte ;
• Des améliorations d’accessibilité ;
• Une nouvelle API permettant de calculer l’altitude pour plusieurs points simultanément, par exemple pour générer des profils altimétriques ;
  
• La prise en charge des cartes nautiques électroniques chiffrées S63 dans le SDK Qt sur toutes les plateformes supportées ;
• La prise en charge des Photo Overlays dans les couches KML ; 
• Un premier support des couches d’imagerie orientée ; 
• le support des proxys forward pour le SDK Kotlin bénéficie du support des proxys forward ; 
• L'intégration des nouvelles API de gestion en arrière plan d'iOS 26 dans le SDK Swift.

Le SDK Flutter poursuit sa montée en puissance vers la parité fonctionnelle, avec l’ajout des entités dynamiques, des utility networks, des API de labellisation, de réduction d’entités et des callouts. Enfin, le SDK .NET abandonne le support de .NET Framework, UWP et Windows x86.

De nombreuses autres évolutions sont disponibles et détaillées dans les notes de version des différents SDK : .NET, Flutter, Kotlin, Qt et Swift.

Conclusion

La version 300.0 représente une évolution majeure pour les SDKs natifs d'ArcGIS, avec des fonctionnalités structurantes qui vont orienter le développement des applications natives dans les années à venir. Esri met ces capacités à disposition pour un usage en production et prévoit de publier prochainement des articles dédiés à certaines de ces nouveautés.

Pour adopter cette version, il suffit de mettre à jour les gestionnaires de dépendances ou de télécharger les dernières versions depuis le site développeur d’Esri. Lors d’une migration depuis la version 200.x, il est recommandé de passer d’abord par la version 200.8 afin de corriger les éventuelles dépréciations, ce qui permettra ensuite de passer à la version 300.0 sans modification supplémentaire du code.

Cette version marque le point de départ d’une série d’évolutions, notamment autour des outils d’analyse et de la vue de scène locale, avec l’ajout progressif de nouvelles capacités dans les versions à venir.