Allez plus loin avec MapKit

Bonjour, moi c’est Alex. Je suis ingénieur au sein de l’équipe MapKit. Apple Plans vous permet de naviguer et d’explorer des endroits du monde entier avec votre appareil. Il y a tant à découvrir, monuments historiques, cafés chaleureux, boutiques locales, superbes itinéraires de rando, etc. Nous verrons aujourd’hui les mises à jour apportées à MapKit et MapKit JS afin d’intégrer les cartes dans vos apps et sites web. Commençons par PlaceDescriptor, une nouvelle façon de rechercher et référencer des lieux. Ensuite, j’aborderai le géocodage et son utilisation pour afficher des informations sur un lieu. Enfin, je vous aiderai à guider les gens à destination avec nos API Directions et Look Around. Commençons par rechercher et référencer des lieux. L’année dernière, nous avons introduit un identifiant pouvant référencer les lieux identifiés par des éléments de carte dans MapKit et par des lieux dans MapKit JS. Les références sont uniques et restent valables dans le temps. Quand l’équipe Plans met à jour les données d’un lieu, comme l’URL d’un site web, une app utilisant un ID de lieu peut afficher ces infos. Ces identifiants étant uniques, l’app peut les utiliser comme clés dans ses structures de données. Les identifiants peuvent être conservés et partagés. Apple assure un suivi de ces données, consultables à tout moment. Les identifiants de lieu restent le meilleur choix pour conserver une référence à un lieu spécifique, trouvé avec MapKit. Mais il y a des cas où cela peut ne pas convenir. Parfois, vous voulez pouvoir trouver les données riches de MapKit pour un lieu précis, même sans identifiant. Par exemple, si vous disposez d’une API Web ou d’un CRM qui vous fournit le nom et l’adresse de tous vos lieux d’activité. Ou peut-être avez-vous le nom et les coordonnées d’un lieu spécifique. Dans ces cas, vous savez que vous recherchez un lieu précis et unique. Ainsi, les API de type recherche locale qui renvoient plusieurs résultats ne conviennent pas. Parfois, je veux transmettre des références de lieu vers ou à partir d’un code que je n’ai pas. Peut-être que je veux vendre des lieux à partir d’un framework. Ou, avec les App Intents, je peux choisir un lieu comme paramètre d’intent, renvoyer un lieu comme résultat d’intent ou ajouter un lieu comme propriété dans mes entités d’app. Dans ces cas, vous pouvez interagir avec d’autres apps n’utilisant pas du tout MapKit. Je peux transmettre un point géographique comme avec CLLocation, mais je ne peux pas l’utiliser pour trouver un lieu d’intérêt riche, comme avec un ID MapKit. Pour tenir compte de ces cas, voici un nouveau type : PlaceDescriptor. C’est dans un nouveau framework : GeoToolbox. PlaceDescriptor vous permet de fournir des infos décrivant un lieu de manière structurée.

Un PlaceDescriptor peut alors être utilisé par MapKit ou d’autres services de cartographie pour trouver des données riches sur ce lieu. Un PlaceDescriptor a trois éléments d’information de haut niveau : une chaîne appelée commonName. Lors de la création d’un PlaceDescriptor, vous devez fournir des noms connus, comme Musée Guggenheim ou Opéra de Sydney. Ce champ ne convient pas aux données privées, comme maison de maman. Son ajout n’aide pas MapKit à trouver votre lieu.

PlaceDescriptor a aussi un ensemble de représentations. Ces représentations sont des formats courants que les apps ou frameworks traitant des infos géographiques devraient pouvoir comprendre. Vous avez le choix entre trois types de PlaceRepresentations. La première est une chaîne d’adresse, comme sur une enveloppe. Fournir la version la plus complète possible de l’adresse offre toutes les chances à MapKit de trouver votre lieu. Viennent ensuite des coordonnées, pour les points fixes, comme un point de repère connu ou un lieu d’affaires. Et enfin, un deviceLocation, qui utilise CLLocation. Il convient aux données GPS reçues et peut avoir des valeurs supplémentaires : précision, horodatage, direction ou vitesse. Le tableau de représentations contient au moins une représentation et est classé par ordre de priorité décroissant. Par exemple, si un PlaceDescriptor provient d’une app de contacts, une coordonnée peut découler de l’adresse de ce lieu. Dans ce cas, l’adresse vient en premier, car c’est la source d’information d’origine et les coordonnées viennent en second. Enfin, PlaceDescriptor a un tableau de représentations de support. Ces représentations ne sont pas utilisables par toutes les apps et ne sont pas obligatoires. Le tableau supportingRepresentations peut être vide. Nous détaillerons plus tard le contenu de supportingRepresentations. Pour présenter PlaceDescriptor et toutes les autres nouvelles API à venir, je vais vous montrer un exemple d’app. C’est aux amateurs de fontaines de les trouver dans des endroits reculés du monde entier. Je voudrais répertorier les fontaines de Dublin intéressantes à visiter et les mettre sur une carte.

Depuis l’arrivée de MapKit pour SwiftUI, j’ai pu créer un marqueur simple sur la carte avec une coordonnée, mais j’aimerais exploiter les riches données d’Apple Plans sur mes fontaines en lien avec toutes les autres API MapKit de mon app, même si je n’ai pas d’ID de lieu. Une excellente occasion d’utiliser PlaceDescriptor. Créons un PlaceDescriptor pour référencer cette fontaine. D’abord, j’importe GeoToolbox. Je sais qu’une fontaine a ces coordonnées. Ainsi, lorsque je crée mon PlaceDescriptor, je fournis une représentation avec coordonnées. Je sais qu’elle s’appelle la fontaine Anna Livia, alors je l’indique aussi. Cela suffit pour créer un PlaceDescriptor valide. Ensuite, je peux importer MapKit et demander un élément de carte avec mon PlaceDescriptor. Une fois que j’ai ma requête, je l’exécute pour obtenir un MKMapItem pour ce lieu. MapItem est le type de base pour les lieux dans MapKit et peut s’utiliser avec diverses API.

Par exemple, je peux utiliser le MapItem sur une carte. Vous verrez que le marqueur affiche le nom, les couleurs et l’iconographie d’Apple Plans pour ce lieu.

Ajoutons un deuxième lieu sur la carte, cette fois en utilisant une adresse pour créer mon descripteur. J’ai juste besoin de fournir la version la plus complète de l’adresse que j’ai pour cette fontaine. Ensuite, je peux créer un PlaceDescriptor avec cela et le nom de la fontaine. J’utilise MKMapItemRequest comme avant et je l’ajoute à la carte avec mon autre fontaine. Rien de plus simple. Voici donc pour PlaceDescriptor et son efficacité à rechercher un lieu avec un nom, et attribuer des coordonnées et une adresse à des PlaceRepresentations. Mais il y a une autre propriété de niveau supérieur de PlaceDescriptor. Il existe un seul type de représentation de support, les ID de service. Une représentation de type ID de service est un dictionnaire où la clé est l’identifiant de lot pour un service de cartographie donné, et la valeur l’ID représentant le lieu pour ce service.

Par exemple, si je connais l’ID de lieu MapKit d’un lieu, je peux créer un dictionnaire dans lequel la clé est com.apple.mapKit et la valeur est l’ID. Ensuite, je crée une représentation serviceIdentifiers et la transmet au paramètre supportingRepresentations de l’initialiseur PlaceDescriptor. Si je connais l’ID de lieu d’un autre fournisseur de services de cartographie, je peux l’indiquer ici. MapKit n’utilise pas d’autres ID, mais leur indication peut être utile dans des scénarios comme App Intents, où vous pouvez fournir un PlaceDescriptor à une autre app n’utilisant peut-être pas MapKit. Vous pouvez fournir autant d’ID que souhaité. Si vous utilisez l’API MapKit, nous faisons toujours ce qu’il faut avec les ID de service. Le cas échéant, MKMapItemRequest utilisera les ID MapKit du PlaceDescriptor pour récupérer le lieu. S’il n’y a pas d’ID MapKit, ou si l’utilisation de l’ID fourni échoue, les autres représentations sur PlaceDescriptor seront utilisées à la place pour trouver votre lieu. De même, si vous créez un PlaceDescriptor avec un MapItem obtenu autrement, nous veillons à ce que le PlaceDescriptor soit renseigné avec toutes les représentations requises, y compris l’ID. Je vais utiliser PlaceDescriptor et MKMapItemRequest pour ajouter le reste des fontaines de Dublin que je connais à mon app. Les MapItems demandés avec un PlaceDescriptor s’utilisent avec toutes nos API MapKit pour afficher des données cartographiques riches comme celles récupérées par ID, ou avec MKLocalSearch.

Par exemple, les fiches de lieu. Après présentation d’une fiche pour un lieu demandé par un PlaceDescriptor, nous pouvons afficher des données riches et à jour (heures d’ouverture), et un lien vers Apple Plans. J’affiche une fiche de lieu quand quelqu’un sélectionne une fontaine dans mon app avec une ligne de code. Les fiches de lieu affichent facilement beaucoup d’infos sur un lieu dans votre app. Consultez « Unlock the power of places with MapKit » de la WWDC 2024 pour en savoir plus.

Cette année, les fiches de lieu dans MapKit JS fournissent également un lien universel vers Apple Plans. Sur les appareils où l’app Plans est installée, des liens s’ouvrent. Et pour les appareils sans app Plans, la fiche de lieu renvoie à maps.apple.com, lancé l’été dernier en version bêta publique. Lorsque vos apps et sites web sont liés à Apple Plans, même ceux situés sur des plates-formes autre qu’Apple peuvent utiliser Plans sur le Web. Avec iOS 18.4, la façon dont Plans gère les URL est actualisée, afin de créer des liens universels similaires en toute confiance. Par exemple, cette URL pour effectuer une recherche. Nous avons rendu les paramètres plus cohérents, simples et faciles à lire.

Nous avons ajouté d’autres paramètres menant à plus de fonctionnalités dans Plans. Consultez la séance « Adopter des URL Plans unifiées » dans les références de cette vidéo, pour ajouter des liens Plans universels dans votre app.

Très bien, j’ai trouvé mes lieux. Voyons maintenant comment utiliser le géocodage et les représentations d’adresses pour plus d’infos sur les lieux dans votre app.

Si vous ne connaissez pas le géocodage, il s’agit de choisir une adresse et de trouver les coordonnées associées. Par exemple, si vous tapez sur une adresse dans l’app Contacts, vous accédez à une carte.

Le géocodage inversé est le contraire. Vous fournissez des coordonnées et nous une adresse. Par exemple, lorsque vous déposez une épingle dans l’app Plans, nous affichons l’adresse de ce lieu.

Sous iOS 18 et avant, vous utilisiez CoreLocation pour effectuer vos tâches de géocodage. Cette année, nous supprimons CLGeocoder, CLPlacemark et intégrons le géocodage à MapKit.

Dans mon app, je veux aussi garder une trace des fontaines trouvées et dont j’ai pris des photos fabuleuses. Ces photos incluent un géotag, qui contient les coordonnées du lieu de la prise, mais je n’ai aucune information à l’appui comme un nom. Je ne peux donc pas utiliser PlaceDescriptor pour trouver le lieu riche. Je n’ai que les coordonnées. Je vais donc utiliser le géocodage inversé dans MapKit pour trouver plus de contexte à afficher.

Appliquons le géocodage inversé à ma première photo de fontaine.

Je vais commencer par les coordonnées du lieu de la photo. Ensuite, je ferai une MKReverseGeocodingRequest avec ce lieu. Contrairement à MKMapItemRequest avec PlaceDescriptor, que je vous ai montré plus tôt, l’initialiseur de MKReverseGeocodingRequests renvoie une option. Si les coordonnées de CLLocation sont non valides, MapKit ne pourra pas effectuer de requête pour vous. Lorsque la demande revient, je reçois un tableau d’éléments de carte. Pour la plupart des demandes de géocodage, ce tableau doit avoir une seule entrée. Je vais donc choisir la première. Comme cet élément de carte provient d’une API de géocodage, il ne contient pas d’informations riches pour un lieu d’intérêt. Ce mapItem ne contient que des informations sur le point d’adresse. Maintenant que j’ai mon élément de carte, je peux afficher l’adresse.

J’utiliserai la requête MKReverseGeocoding pour obtenir une adresse pour mes autres photos et les afficher dans une liste. Mon app prend forme, mais je pense que l’adresse complète est trop détaillée pour cet écran. Je vais donc m’intéresser aux autres options. MKMapItem offre deux propriétés facultatives pour accéder aux infos d’adresse.

Tout d’abord, MKAddress. Vous pouvez instancier votre MKAddress lorsque vous créez votre MKMapItem. Et MapKit fournit une MKAddress lors du renvoi de MapItems à partir d’API comme le géocodage, la recherche locale et la résolution PlaceDescriptor. Deuxièmement, MKAddressRepresentations, qui n’a pas d’initialiseur. Les représentations d’adresses ne figurent que sur les éléments de carte renvoyés par les API MapKit.

Commençons par MKAddress. Elle a deux propriétés de type chaîne, fullAddress et shortAddress.

FullAddress est la version la plus complète d’une adresse postale ou administrative, tandis que shortAddress ne fournit que les aspects essentiels.

Parfois, l’adresse que nous fournissons peut être très brève. Ainsi, un géocodage inversé pour des coordonnées au milieu de l’océan peut comporter une seule ligne.

Lorsque vous instanciez votre MapItem, la propriété d’adresse est utilisée dans les fiches de lieux MapKit, ce qui permet d’afficher vos informations d’adresse.

Si MKAddress fournit les versions simples d’une adresse, MKAddressRepresentations offre des moyens efficaces d’afficher ces informations dans votre app. Si vous souhaitez afficher une liste d’adresses complètes qui figurent toutes dans le même pays, vous pouvez omettre la zone géographique dans l’interface de votre app. Pour cela, vous utilisez fullAddress(includingRegion: false). Ou peut-être voulez-vous lister la ville et du contexte supplémentaire sur le lieu de la ville. Parfois, vous voulez indiquer un État ou une province comme Los Angeles, Californie. D’autres fois, vous voulez inclure le pays comme Paris, France. MapKit vous facilite la tâche en choisissant ce qui convient pour votre adresse, ainsi que la langue et la zone géographique de l’appareil demandant l’élément de carte. Maintenant que j’en sais plus sur les différentes représentations d’adresses pour mon app, je vais choisir cityWithContext pour rendre plus concises les infos d’adresse affichées avec mes photos. J’affiche le bon niveau de détail pour mon app, et elle a fière allure.

L’API pour le géocodage direct est très similaire au géocodage inversé. Avec MKGeocodingRequest, je peux récupérer un MapItem, cette fois pour mon adresse. Il est ainsi très facile d’accéder aux coordonnées ou de les ajouter à une carte. Toutes les options évoquées pour les informations d’adresse sont présentes, afin d’obtenir les représentations d’affichage pour mon adresse que je n’avais pas avant la demande de géocodage.

Maintenant que j’ai trouvé mes lieux et affiché quelques infos à leur sujet, je vais vous montrer les API MapKit pour vous aider à y accéder. MapKit dispose d’une API Directions, qui identifie les infos pour aller d’un point A à un point B via plusieurs modes de transport (marche, conduite). Directions fournit des estimations de temps et de distance, ainsi que des infos détaillées sur toutes les étapes en cours de route.

Revenons sur ma carte de Dublin. J’aimerais planifier les itinéraires vers les fontaines retenues. J’active la sélection en indiquant un lien d’élément de carte dans mon initialiseur de cartes. Je peux alors calculer l’itinéraire lorsque l’élément sélectionné change. Pour savoir comment gérer la sélection de cartes, regardez « Meet MapKit for SwiftUI » de la WWDC 2023. Pour obtenir mon trajet, je crée une demande d’itinéraire. Je définis ensuite le lieu de l’appareil comme la source et l’élément de carte comme la destination. Ensuite, je crée un objet Directions. Et enfin, je calcule mon itinéraire. Je m’assure de gérer les erreurs éventuelles, puis je traite la réponse. Mais que contient la réponse à une demande d’itinéraire ?

La source et la destination correspondant à votre itinéraire sont renvoyées. Celles-ci peuvent légèrement différer de celles figurant dans votre demande. Ainsi, les instructions routières peuvent intégrer le stationnement, et les instructions piétonnes vous mener directement à un bâtiment.

Nous ajoutons aussi un tableau avec un ou plusieurs itinéraires répondant à votre demande.

Les itinéraires contiennent de nombreuses infos utiles, notamment un nom localisé utilisable comme titre d’itinéraire, un ensemble d’indications pertinentes, comme les fermetures de routes, la distance en mètres, le temps requis pour le trajet et la géométrie de l’itinéraire, qui peut être dessinée sur une carte.

Je suis ravi de vous annoncer que cette année, MapKit intègre les itinéraires pour cyclistes. Pour mon app, le vélo est le moyen idéal pour voir les fontaines de Dublin. Il suffit juste de modifier une propriété sur ma demande d’itinéraire. Pour afficher un chemin cyclable éventuel pour mes itinéraires, je choisis le premier itinéraire de la réponse. Et je l’ajoute à ma carte avec MapPolyline. C’est aussi simple que cela.

Les itinéraires cyclables avec MapKit sont efficaces. Ils tirent parti des chemins et sentiers non disponibles en voiture et omettent certaines routes inadaptées aux vélos. Vous pouvez aussi obtenir des itinéraires cyclistes et des estimations d’arrivée avec MapKit JS. Tout comme avec Swift, il me suffit d’ajouter une ligne de configuration à ma demande d’itinéraire existante pour indiquer le vélo comme transport.

Autre info, vous pouvez maintenant obtenir des itinéraires avec MapKit sur watchOS ! Plus de 20 API MapKit ont été intégrées à Apple Watch avec le dernier SDK watchOS.

Ayant maintenant un bon itinéraire cyclable pour mon Fountain Tour, je me sentirais encore plus à l’aise de pouvoir l’explorer avant de partir. Avec la fonction Look Around de Plans, j’obtiens des images interactives à 360° de la ville pour prévisualiser les routes, les pistes cyclables, les parkings et les points de repère.

Nous avons intégré Look Around aux apps MapKit dans iOS 16, y compris des API pour vérifier l’emplacement des images, les prévisualiser et les afficher en plein écran. Pour en savoir plus, consultez la séance « What’s new in MapKit » de la WWDC 2022.

Cette année, nous intégrons Look Around à MapKit JS, afin de pouvoir l’activer dans votre site web ou app web. Vous pourrez ajouter deux types de vues Look Around.

La première est la vue interactive, qui permet d’intégrer une vue exploitable par l’utilisateur dans votre interface. La seconde est l’aperçu de la vue Look Around. Il s’agit d’un instantané statique des images à l’endroit souhaité. En cliquant sur l’aperçu, vous initiez une expérience interactive en plein écran. Pour ajouter une vue interactive à mon site web, j’ai besoin d’un objet de type lieu. Je peux utiliser tout type d’API MapKit JS, comme rechercher un lieu, rechercher ou géocodage. Dans ce cas, j’ai un identifiant, je vais donc utiliser placeLookup. Ensuite, je crée un objet Look Around, en passant par l’élément DOM qui le contient, ainsi que mon objet lieu, et enfin un dictionnaire d’options. Il existe trois options prises en charge par LookAroundView. La première est openDialog. Avec une valeur true pour cette option, LookAroundView couvre toute la fenêtre du navigateur. La deuxième est showsDialogControl. Avec une valeur true, un bouton apparaît dans LookAroundView pour vous permettre d’activer ou désactiver la fenêtre complète. Et enfin, showsCloseControl. Avec une valeur true, un bouton permet de fermer la vue Look Around. MapKit JS stipulera divers événements liés à LookAroundView. Vous pouvez ajouter des écouteurs d’événements pour traiter/remplacer les comportements par défaut. Par exemple, un appui sur le bouton de fermeture déclenche un événement de fermeture. Ce rappel permet d’effectuer des animations ou des changements d’état utiles dans votre app.

Sans annulation de l’action par défaut pour cet événement, la vue lookAround sera supprimée du DOM. D’autres événements que vous voudrez peut-être gérer : L’événement Load, qui se déclenche lorsque la vue est entièrement chargée. L’événement Error, qui se déclenche en cas de problème. Par exemple, quand les images sont indisponibles ou que le navigateur ne peut pas afficher la vue. MapKit JS fournit une interface d’erreur, mais peut-être voulez-vous votre propre scénario d’erreur ou de secours. Enfin, lookAround envoie des événements readystatechange, utilisables pour surveiller le cycle de vie de la vue. L’état prêt change lorsque la vue est en cours/fin de chargement, comporte une erreur ou est supprimée du DOM. Outre LookAroundView, l’API Look Around Preview vous permet d’obtenir une expérience plus simple. Les aperçus Look Around ne sont pas interactifs. Aucun panoramique n’est possible. Un clic sur l’aperçu Look Around lance une fenêtre complète de visualisation. Je pense qu’avec LookAround et MapKit JS, vos sites web atteindront un niveau supérieur. Voilà pour conclure notre séance. Vous avez reçu une foule d’infos. Je vous ai montré comment trouver des lieux, afficher des informations sur ceux-ci et parcourir le monde avec MapKit et MapKit JS.

Avant de terminer, voici quelques devoirs. Utilisez PlaceDescriptor pour rechercher des lieux avec ou sans identifiant, et pour envoyer des références à d’autres apps. Actualisez tous les liens vers Apple Plans pour utiliser le nouveau format d’URL unifiée.

Transférez vos apps de CoreLocation vers les API MapKit pour le géocodage et tirez parti de nos représentations d’adresses. Enfin, ajoutez à votre app des itinéraires cyclables et une vue Look Around pour aider les gens à s’orienter.

Merci d’être passé et d’avoir découvert MapKit avec moi aujourd’hui !