Une carte en temps réel combine un canevas géographique stable avec des données opérationnelles mises à jour en temps réel : positions des véhicules, état des ressources, incidents, disponibilité ou état des capteurs. L’important est d’obtenir une image opérationnelle en temps réel, et non une simple mise à jour des marqueurs. Kaleidr Studio centralise actuellement les couches de données dynamiques, les ressources mobiles, les fonds de carte personnalisés, la visualisation 3D, les préréglages réutilisables et la publication au sein d'une interface de création unique (Kaleidr, 2026).
Les sections suivantes expliquent la différence entre une carte interactive classique et une image opérationnelle en temps réel, puis détaillent la place de Studio dans le flux de travail, la mise à jour des données, la manière dont l'état actuel est intégré à la carte, les projets B2B, la publication et la mesure. Pour en savoir plus, consultez Cartes interactives personnalisées dans Kaleidr Studio, Cartes 3D dans Kaleidr Studio, Guide de publication de cartes et Comment créer un fond de carte personnalisé. La suite de cet article s'adresse aux équipes disposant déjà d'un flux opérationnel et ayant besoin d'une interface spatiale personnalisée, et non à celles qui remplacent une plateforme de gestion de flotte, de répartition ou IoT.
Principes fondamentaux de la cartographie en temps réel
- Présentation stable : La carte de base n'est reconstruite que lorsque la conception change, et non lorsqu'un élément est déplacé.
- Source faisant autorité : Studio conçoit l'expérience spatiale ; le système opérationnel conserve l'état actuel.
- La fraîcheur des données est un champ : L'âge, l'état de la connexion et l'indisponibilité doivent figurer sur la carte, et pas seulement dans les journaux.
- Identité stable : La géométrie et l'état sont mis à jour avec le même identifiant d'élément ; il est inutile de créer une nouvelle entité à chaque requête.
- Séparez le direct et l'historique : L'état actuel et la lecture ne partagent pas une couche non identifiée.
Les cartes en temps réel sont optimales lorsque la présentation reste stable malgré l’évolution des données opérationnelles sous-jacentes.
Qu’est-ce qui différencie une carte en temps réel d’une carte interactive statique ?
Un localisateur de magasins, un guide de destination ou un catalogue immobilier peuvent rester utiles lorsque les emplacements ne changent qu’occasionnellement. Une carte opérationnelle en temps réel implique une contrainte plus stricte : l’utilisateur visualise l’image actuelle, et un marqueur obsolète peut entraîner une mauvaise répartition, un incident manqué ou une fausse impression de mouvement du véhicule. La fraîcheur des données, la fréquence des mises à jour, la fiabilité des sources, les transitions d'état, la gestion des erreurs et la stabilité visuelle doivent donc faire partie intégrante du contrat produit, et non être considérées comme des considérations a posteriori une fois l'interface utilisateur satisfaisante.
En pratique, il s'agit de déterminer si des données obsolètes influencent la décision. La gestion des flottes nécessite souvent des mises à jour toutes les quelques secondes. La disponibilité des parkings, le statut des équipes sur le terrain ou le taux d'occupation des installations peuvent être utiles avec un intervalle de 30 à 60 secondes. L'état des stocks ou des bâtiments peut attendre plusieurs minutes. Une actualisation inférieure à la seconde est réservée aux systèmes de contrôle spécialisés, et non à toutes les cartes destinées aux clients. La fréquence de mise à jour doit tenir compte de la durée de vie admissible des informations avant que la prochaine action ne soit erronée.
Une carte interactive classique peut masquer un enregistrement manquant en affichant un résultat vide. Une carte en temps réel doit faire la distinction entre « aucune activité » et « la transmission des données a échoué ». Un véhicule immobile depuis dix minutes peut être stationné, ou le dernier point de données peut être obsolète. Une icône d'incident qui disparaît peut être résolue, ou la connexion peut avoir été interrompue. Ces deux situations nécessitent des libellés différents, un niveau de confiance différent et souvent des actions différentes de l'opérateur.
Quelle est la place de Kaleidr Studio en tant que couche de création visuelle ?
Kaleidr Studio est conçu pour permettre aux équipes de créer des cartes interactives personnalisées avec Kaleidr AI, puis de modifier les styles, les calques, les emplacements, le contenu et les expériences interactives. Tuiles de carte personnalisées et fonds de carte de marque, calques réutilisables et préréglages de style, terrain 3D, calques de données en temps réel, suivi de flotte et d'actifs, et publication sont intégrés dans la même interface de création. Studio permet de transformer les données opérationnelles modifiées en une expérience spatiale personnalisée. Le système opérationnel reste la source des positions et de l'état actuels.
La hiérarchie du fond de carte reste essentielle lorsque les marqueurs se déplacent. Les routes, l'eau, les étiquettes et le relief doivent s'estomper pour que les véhicules, les tâches, les zones de service et les alertes restent lisibles. L'identité de marque doit guider la carte ; le statut doit toujours être lié à la fonction. Comment créer un fond de carte personnalisé aborde la question de la dimension géographique. Des préréglages réutilisables, nommés d'après la tâche (surveillance opérationnelle, suivi des actifs en temps réel, gestion d'événements), réduisent la dérive entre plusieurs cartes dynamiques sans imposer une densité uniforme à chaque surface.
La 3D doit rester contextuelle. Studio inclut le terrain, l'ombrage, l'altitude réelle et les bâtiments extrudés. Une caméra inclinée peut clarifier les installations, les campus ou les sites d'événements denses, mais une flotte en mouvement nécessite un actif sélectionné lisible, et non une inclinaison décorative masquant le statut. Cartes 3D dans Kaleidr Studio explique quand la profondeur est utile. Les couches dynamiques nécessitent des rôles visuels supplémentaires, tels que « actuel », « récent », « obsolète », « hors ligne » et « alerte », afin que les cartes opérationnelles partagent un langage commun.
Comment une carte stable doit-elle s'intégrer aux données opérationnelles changeantes ?
Une carte dynamique de production est généralement alimentée par une source opérationnelle de référence, via un flux d'état actuel (API), puis par validation et normalisation, avant d'être intégrée à une couche spatiale dynamique sur une carte conçue avec Studio, et enfin affichée dans une visionneuse publiée ou intégrée où un opérateur peut interagir. Les systèmes de gestion de flotte, d'IoT, de répartition, de réservation, d'incidents, d'inventaire et d'actifs restent la source de référence. Studio contrôle l'organisation, le style, la superposition et l'affichage spatial de ces informations.
Le modèle mental utile est celui d'une présentation stable associée à un état opérationnel changeant. Le fond de carte, les étiquettes, les routes, le terrain, les bâtiments et les zones de service statiques restent inchangés. Les véhicules, les livraisons, les incidents, les tâches, la disponibilité, les alertes et les valeurs des capteurs peuvent évoluer. Reconstruire la carte entière à chaque requête gaspille les ressources de rendu et provoque des problèmes de fluidité avec la caméra. La structure de la carte doit être conservée même lorsque les éléments concernés se mettent à jour.
Les éléments mobiles nécessitent des identifiants stables. Chaque véhicule, technicien, tâche ou installation doit conserver une identité unique, même si sa longitude, sa latitude, son statut, son cap et updatedAt changent. Un véhicule sélectionné doit rester sélectionné lors de ses déplacements. Créer un nouvel élément à chaque requête de localisation perturbe la sélection, l'historique et les analyses. MapLibre GL JS illustre ce principe de conservation d'identité dans une carte de navigateur : GeoJSONSource.setData() remplace GeoJSON dans une source et effectue un nouveau rendu, et updateData() peut appliquer une différence lorsque chaque élément possède déjà un identifiant unique (MapLibre, 2026). Studio conserve la maîtrise de la conception des couches dynamiques en plus de ce type de mise à jour : identifiants stables, fraîcheur et carte publiée.
GeoJSON est un format d'échange courant pour les points, lignes et polygones dynamiques dans les cartes web, mais il ne s'agit pas du seul format de stockage utilisable par un système hôte. Une entité peut contenir un statut et un horodatage dans ses propriétés, tandis que sa géométrie indique la position ou l'itinéraire actuel. Les applications hôtes continuent de valider les coordonnées, de rejeter les identifiants inconnus et de masquer les champs opérationnels privés sur la carte publique. La hiérarchie des couches doit placer la géographie de référence sous les ressources dynamiques, et les alertes ou l'entité sélectionnée au-dessus.
Conservez le système opérationnel comme source de référence et utilisez Studio pour contrôler la présentation spatiale.
Comment la mise à jour des données doit-elle apparaître sur une carte dynamique ?
Chaque enregistrement dynamique doit comporter un horodatage que l'interface utilisateur peut convertir en ancienneté des données. Les seuils éditoriaux tels que « actuel » (moins de 15 secondes), « récent » (moins d'une minute), « obsolète » (moins de cinq minutes) et « indisponible » (ensuite) sont des exemples et non un schéma Kaleidr. Le contexte métier définit les intervalles : une camionnette stationnée et une position GPS abandonnée ne doivent pas partager le même indicateur de fiabilité. L'état de la connexion (connecté, retardé, en cours de reconnexion, déconnecté) doit être indiqué à côté de l'élément, car un dernier point connu, même s'il est précis, peut être pire qu'une carte vide.
Ne masquez pas les données obsolètes en laissant la dernière icône sans étiquette. Les états utiles incluent : en direct, dernière mise à jour il y a un nombre de secondes spécifié, obsolète, flux indisponible et localisation inconnue. La couleur seule ne suffit pas. Associez la teinte à l'icône, au texte et à l'horodatage afin qu'un opérateur ne pouvant se fier à la couleur puisse tout de même évaluer la fiabilité. Une trace en direct peut indiquer un mouvement récent ; un élément obsolète ne doit pas conserver une trace de mouvement suggérant qu'il est toujours en déplacement.
L'état en direct et l'historique répondent à des questions différentes. L'état actuel indique la position actuelle de la ressource. L'historique indique ses déplacements, les itinéraires empruntés et la date d'ouverture d'un incident. Mélanger les deux sur une même couche non marquée donne l'impression que le trajet d'hier correspond à la tâche d'aujourd'hui. La lecture de l'historique doit être un mode étiqueté, avec son propre curseur temporel, afin d'éviter toute confusion entre une rediffusion et l'image en direct. Le fuseau horaire doit être clairement indiqué lorsque les opérateurs sont répartis sur plusieurs régions.
Les états vide, partiel et en cours de reconnexion font partie intégrante de la conception. L'absence de ressources peut correspondre à une période d'inactivité réelle. Un flux partiel peut signifier qu'une région est connectée tandis qu'une autre a expiré. La reconnexion ne doit pas faire disparaître tous les marqueurs comme si la coupure n'avait jamais eu lieu. Des mises à jour ordonnées, des rafales fusionnées et une étiquette explicite « Flux en cours de récupération » garantissent l'exactitude de la carte pendant les tentatives de reconnexion.
Une carte en temps réel doit afficher la fraîcheur des données afin que les données anciennes ne paraissent jamais à jour.
La comparaison suivante est donnée à titre indicatif. Les déploiements réels doivent remplir les mêmes colonnes à partir du flux qu'ils utilisent déjà.
| État | Lecture par l'opérateur | Traitement visuel typique |
|---|---|---|
| En direct | Actuel pour la prochaine action | Opacité totale, mouvement uniquement si l'élément est en mouvement |
| Récent | Utilisable, avec une ancienneté visible | Marqueur complet plus « mis à jour il y a n secondes » |
| Obsolète | Ne pas déclencher sur la seule base de ce critère | Fiabilité réduite, étiquette obsolète, aucune trace de mouvement |
| Flux Indisponible | La carte ne peut pas déterminer votre position actuelle | État indisponible ou localisation inconnue |
Comment les données en temps réel doivent-elles parvenir à la carte ?
L'application hôte transfère l'état actuel à la carte. L'interrogation est simple et optimisée pour le cache lorsque l'intervalle de décision est de l'ordre de quelques dizaines de secondes ou minutes. Les événements envoyés par le serveur permettent à ce dernier d'envoyer des messages au navigateur via une connexion unidirectionnelle persistante (MDN Web Docs, 2026). L'API WebSocket ouvre une session bidirectionnelle permettant au client d'envoyer et de recevoir des données sans interrogation. MDN note que l'interface standard WebSocket ne gère pas la contre-pression ; une application qui ne peut pas suivre le rythme peut donc saturer la mémoire ou devenir non réactive (MDN Web Docs, 2026). Choisissez le mode de transport en fonction de la fréquence de mise à jour, de la directionnalité, de l'infrastructure et du volume. Studio reste responsable de la couche visuelle : fond de carte, style des calques dynamiques, gestion de la fraîcheur et expérience utilisateur publiée.
L'utilisation d'un instantané suivi d'un flux continu est un modèle de production robuste. Le client charge un ensemble actuel validé, puis applique des mises à jour incrémentales ordonnées. Le remplacement complet est plus facile à appréhender pour les petits ensembles. Les mises à jour incrémentales sont plus performantes lorsque des milliers d'éléments sont déplacés, à condition que les identifiants soient stables et que les messages manqués puissent être corrigés. L'exemple de données en temps réel de MapLibre modifie un point de manière répétée et appelle setData() sur la source GeoJSON (MapLibre, 2025). Ce même schéma d'instantané puis de mise à jour est celui dont un calque dynamique Studio a besoin du flux opérationnel : les entités actuelles, puis les modifications ordonnées, avec des identifiants qui ne sont pas réinitialisés à chaque requête.
Les informations d'identification restent sur le serveur. Le navigateur ne doit recevoir que les champs nécessaires à la vue publiée : position publique, statut approximatif et actualité, et non les notes de répartition internes, les données personnelles des clients ou les clés de service. Les cartes clients publiques et les cartes d'opérations internes doivent être des vues distinctes, même si elles partagent un fond de carte. La minimisation des données est une exigence produit, et non une simple formalité juridique.
L'animation doit illustrer les mouvements de manière pertinente, et non pas orner chaque point de repère. Le mode de suivi de la caméra est utile lorsqu'un opérateur suit un élément précis, mais nuisible lorsqu'il empêche un utilisateur d'effectuer un panoramique ou un zoom sur une zone. À faible zoom, il est préférable de regrouper ou d'agréger les éléments plutôt que de dessiner chaque véhicule. Les grands ensembles de données nécessitent une fusion, un filtrage de la fenêtre d'affichage et une gestion des mises à jour plus rapides que la capacité de rendu. La carte doit rester une surface de décision sous charge, et non un système de particules.
Quels cas d’usage B2B nécessitent des cartes en temps réel dans Kaleidr Studio ?
Les données en temps réel varient selon les secteurs d'activité, mais la couche de conception Studio garantit une expérience spatiale cohérente : fond de carte personnalisé, calques dynamiques, préréglages réutilisables, contexte 3D optionnel et visionneuse intégrée ou publiée. Kaleidr publie actuellement un modèle de localisation pour le suivi en temps réel des flottes et des équipements sur le terrain, ainsi que des points de départ pour l'hôtellerie, l'immobilier et le commerce de détail (Kaleidr, 2026). Studio fournit la carte créée. Le modèle fournit la structure de la page.
Les cartes de flottes et de logistique doivent indiquer quels équipements nécessitent une intervention, et non le nombre de marqueurs mobiles. Les champs habituels sont : position actuelle, statut, itinéraire, tâche assignée, zone de service, dernière mise à jour et état d'alerte. Le service sur le terrain combine techniciens, interventions, zones de service et localisation en temps réel, permettant ainsi à un opérateur d'inspecter, de réaffecter ou d'ouvrir un itinéraire. Les cartes des installations mettent en évidence les incidents d'équipement dans un contexte stable d'étage ou de campus. L'organisation d'événements prévoit la mise en place de zones temporaires et d'équipes de service dédiées uniquement à la durée de l'événement. Les portefeuilles immobiliers et les réseaux de distribution affichent plus souvent la disponibilité, l'état d'ouverture ou l'état d'incident que des mouvements constants.
Les alertes doivent constituer une couche structurée, et non une simple amplification de l'état brut. Une violation de zone géographique, une ressource prioritaire obsolète ou un incident dans une zone visible par le client nécessitent un traitement spécifique et une action immédiate. Les règles spatiales, telles que « à l'intérieur d'une zone de service », « à l'extérieur d'une zone géographique » ou « à proximité d'un incident », relèvent de l'application hôte qui gère déjà ces politiques. Un assistant cartographique IA superposé à une carte en temps réel ne doit pas reconstituer l'état actuel à partir de données d'entraînement. Le système opérationnel reste la référence ; le modèle de langage peut interpréter les enregistrements validés une fois que l'application les a autorisés.
Différents secteurs utilisent des données en temps réel différentes, mais la couche de conception Studio permet de garantir une expérience spatiale cohérente.
Comment les équipes doivent-elles publier, mesurer et maintenir la lisibilité de la carte ?
Une carte en temps réel qui s'affiche correctement dans Studio peut présenter des dysfonctionnements dans le conteneur publié. Testez les états de chargement, de données vides, de flux partiel, d'obsolescence et de reconnexion sur la surface réelle, aux niveaux de zoom utilisés par les opérateurs, sur des appareils mobiles et avec des mouvements réduits. Le Guide de publication de cartes traite du transfert en production. Les pages autonomes, les intégrations et les intégrations de produits doivent hériter du même fond de carte, des mêmes rôles de couche en temps réel et de la même langue d'état sélectionné. Gérez les versions du système visuel afin qu'une modification ultérieure d'un préréglage n'affecte pas silencieusement le style de la carte opérationnelle de la veille.
La mesure doit inclure l'état du flux, et pas seulement le nombre de pages vues. Kaleidr Analytics mesure les chargements de cartes, les sessions, les interactions, l'engagement des lieux et les modèles spatiaux (Kaleidr, 2026). L'ancienneté des données, le taux d'éléments obsolètes, les reconnexions, le temps de sélection d'une ressource et les actions opérationnelles lancées constituent les diagnostics supplémentaires de la carte en temps réel qui s'ajoutent à ces mesures d'engagement. Analyse spatiale vs. Analyse Web explique pourquoi le nombre de sessions ne permet pas à un opérateur de déterminer si l'image en direct était fiable. Il est important de vérifier si les utilisateurs accomplissent la tâche pour laquelle la carte a été créée.
Utilisez Studio en priorité lorsque le travail concerne la hiérarchie du fond de carte, la marque, le style des calques, les préréglages, le contexte 3D et la publication d'une expérience spatiale en direct sur un flux appartenant déjà à l'hôte. Utilisez une intégration personnalisée plus poussée lorsque le produit nécessite une interaction spécialisée avec la salle de contrôle ou une logique applicative allant au-delà de la simple création de cartes. Un tableau de bord de surveillance peut afficher des tableaux et des graphiques. Une carte en temps réel doit toujours permettre de visualiser clairement le lieu, la fraîcheur des informations et l'action suivante.
Explorez Kaleidr Studio pour concevoir des fonds de carte personnalisés, des calques dynamiques, des préréglages et des expériences cartographiques publiées. Explorez Kaleidr Analytics pour mesurer l'engagement des utilisateurs après la mise en ligne de la carte.
FAQ
Qu'est-ce qu'une carte en temps réel ?
Une carte en temps réel affiche des données spatiales qui évoluent pendant que l'utilisateur la consulte, comme les véhicules en mouvement, les incidents, la disponibilité, l'état opérationnel ou l'état des capteurs en direct.
Le terme « temps réel » signifie-t-il toujours des mises à jour instantanées ?
Non. L'intervalle de mise à jour approprié dépend de la rapidité avec laquelle les données obsolètes influencent la décision de l'utilisateur. Certains flux de travail nécessitent quelques secondes ; d'autres peuvent se rafraîchir toutes les minutes ou toutes les quelques minutes.
Quel est le champ le plus important dans une carte interactive ?
L'identité stable des entités et un horodatage fiable des mises à jour sont tous deux essentiels. Sans identité, les mises à jour ne peuvent pas être correctement synchronisées ; sans actualisation, un état ancien peut sembler actuel.
Une carte interactive doit-elle utiliser WebSockets ?
Pas nécessairement. L'interrogation, les événements envoyés par le serveur et WebSockets sont tous des modèles valides, selon la fréquence de mise à jour, la direction, l'infrastructure et l'échelle.
Quelles sont les fonctionnalités de cartographie en temps réel incluses dans Kaleidr Studio ?
Kaleidr Studio inclut des couches de données en temps réel, le suivi des actifs mobiles, des fonds de carte personnalisés, la visualisation 3D, des couches réutilisables et des expériences cartographiques publiées.
Comment les données en temps réel se connectent-elles à une carte Studio ?
Studio conçoit la carte personnalisée, les couches en temps réel et l'expérience publiée. Le système opérationnel reste la source de l'état actuel, et l'application hôte fournit les mises à jour via le chemin d'intégration choisi pour ce déploiement.
Kaleidr Studio peut-il suivre des flottes ?
Kaleidr Studio permet le suivi des véhicules, des flottes et des flux en direct. Kaleidr publie également un modèle de localisation pour le suivi en direct des flottes et des équipements sur le terrain.
Quelle est la différence entre les données en direct et les données historiques sur une carte ?
Les données en direct représentent l’état actuel. Les données historiques représentent les états ou les mouvements précédents. Il est généralement recommandé de les modéliser comme des calques distincts ou via un mode de lecture clairement indiqué.
Comment une carte doit-elle afficher les données obsolètes ?
Utilisez un indicateur explicite d’obsolescence, une étiquette d’âge, un style de confiance réduite ou un état indisponible plutôt que d’afficher la dernière position connue comme étant incontestablement actuelle.
Les cartes en temps réel peuvent-elles utiliser GeoJSON ?
Oui. GeoJSON est couramment utilisé pour représenter des points, des lignes et des polygones dynamiques dans les cartes web. MapLibre, par exemple, peut mettre à jour une source GeoJSON avec setData() et actualiser la carte.
Faut-il animer tous les éléments mobiles ?
Non. L’animation doit aider les utilisateurs à comprendre les mouvements. Une animation excessive peut nuire à la lisibilité et aux performances.
Comment mesurer les performances d’une carte en temps réel ?
Suivre la disponibilité du flux RSS, l’ancienneté des données, la latence de mise à jour, le taux d’éléments obsolètes, les reconnexions, les performances d’affichage et les actions effectuées par les utilisateurs sur la carte.
Références
- Kaleidr. AI Map Maker for Branded Interactive Maps. Accessed 21 September 2026. https://kaleidr.com/studio
- Kaleidr. Map Website Templates. Accessed 21 September 2026. https://template.kaleidr.com/
- MapLibre. GeoJSONSource. MapLibre GL JS API. Accessed 21 September 2026. https://maplibre.org/maplibre-gl-js/docs/API/classes/GeoJSONSource/
- MapLibre. Add live realtime data. MapLibre GL JS Examples. Page metadata lists creation on 25 June 2025; accessed 21 September 2026. https://maplibre.org/maplibre-gl-js/docs/examples/add-live-realtime-data/
- MDN Web Docs. WebSocket API (WebSockets). Last modified 12 September 2026. https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
- MDN Web Docs. Server-sent events. Accessed 21 September 2026. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
- Kaleidr. Map Engagement and Location Analytics. Accessed 21 September 2026. https://kaleidr.com/analytics
- Kaleidr. Branded Interactive Maps in Kaleidr Studio. Accessed 21 September 2026. https://kaleidr.com/blog/branded-interactive-maps-in-kaleidr-studio
- Kaleidr. 3D Maps in Kaleidr Studio. Accessed 21 September 2026. https://kaleidr.com/blog/3d-maps-kaleidr-studio
- Kaleidr. Map Publishing Guide. Accessed 21 September 2026. https://kaleidr.com/blog/map-publishing-guide
- Kaleidr. How to Build a Custom Branded Basemap. Accessed 21 September 2026. https://kaleidr.com/blog/how-to-build-a-custom-branded-basemap
- Kaleidr. Spatial Analytics vs. Web Analytics. Accessed 21 September 2026. https://kaleidr.com/blog/spatial-analytics-vs-web-analytics
@misc{kaleidr_studio_realtime_2026,
title = {AI Map Maker for Branded Interactive Maps},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/studio}
}
@misc{kaleidr_template_store_realtime_2026,
title = {Map Website Templates},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://template.kaleidr.com/}
}
@misc{maplibre_geojson_source_2026,
title = {GeoJSONSource},
author = {{MapLibre}},
year = {2026},
note = {MapLibre GL JS API; accessed 21 September 2026},
url = {https://maplibre.org/maplibre-gl-js/docs/API/classes/GeoJSONSource/}
}
@misc{maplibre_live_data_2025,
title = {Add live realtime data},
author = {{MapLibre}},
year = {2025},
note = {MapLibre GL JS Examples; og:created 2025-06-25; accessed 21 September 2026},
url = {https://maplibre.org/maplibre-gl-js/docs/examples/add-live-realtime-data/}
}
@misc{mdn_websocket_2026,
title = {WebSocket API (WebSockets)},
author = {{MDN Web Docs}},
year = {2026},
note = {Last modified 12 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API}
}
@misc{mdn_sse_2026,
title = {Server-sent events},
author = {{MDN Web Docs}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events}
}
@misc{kaleidr_analytics_realtime_2026,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_branded_maps_studio_2026,
title = {Branded Interactive Maps in Kaleidr Studio},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/blog/branded-interactive-maps-in-kaleidr-studio}
}
@misc{kaleidr_3d_maps_studio_2026,
title = {3D Maps in Kaleidr Studio},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/blog/3d-maps-kaleidr-studio}
}
@misc{kaleidr_map_publishing_2026,
title = {Map Publishing Guide},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/blog/map-publishing-guide}
}
@misc{kaleidr_branded_basemap_2026,
title = {How to Build a Custom Branded Basemap},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/blog/how-to-build-a-custom-branded-basemap}
}
@misc{kaleidr_spatial_vs_web_analytics_2026,
title = {Spatial Analytics vs. Web Analytics},
author = {{Kaleidr}},
year = {2026},
note = {Accessed 21 September 2026},
url = {https://kaleidr.com/blog/spatial-analytics-vs-web-analytics}
}