Brevet FR3042620A1 — publié le 20170421

F4GROUP6.FRD Dispositif Web interactif à affichage personnalisable L'invention concerne le domaine des dispositifs web, et en particulier les dispositifs permettant une interaction. Plus particulièrement, l'invention concerne le domaine de la cartographie sur Internet. La cartographie sur Internet a longtemps été limitée à la reproduction de cartes papiers sous forme d'images. Cela était imprécis et fortement consommateur en bande passante, et posait des problèmes de pertinence, puisque les images n'offraient pas de moyen simple de mise à l'échelle ni de personnalisation. Des acteurs importants des nouvelles technologies ont modifié cette situation en proposant des cartes sur Internet qui étaient plus légères, dont la mise à l'échelle est adaptative, et qui permettent à l'utilisateur de parcourir rapidement une carte donnée. Pour note, comme l'invention, ces solutions sont toutes de type « pur Web », c'est-à- dire qu'un client Web (un navigateur ou une application de smartphone) interagit avec un serveur pour obtenir les données, mais ne stocke rien en local, hormis du cache. Toutes les données proviennent du serveur, en temps réel sauf pour les données du cache. Cela est crucial car, compte tenu des bandes passantes actuellement disponibles, les contraintes sur ce qu'il est possible d'obtenir en termes d'effets visuels sont très fortes si l'on souhaite maintenir un affichage fluide. Ces mêmes acteurs ont rajouté sur ces cartes des couches (« layer » en anglais) d'information afin d'ajouter un peu d'information, comme l'emplacement de certains commerces ou monuments, etc. Cependant, il s'agit littéralement de couches au sens graphique du terme : la nature de l'interaction est limitée à l'affichage d'un texte, la zone cliquable permettant cette interaction est limitée à une zone de taille réduite choisie de manière arbitraire, et ne peut pas par exemple concerner un immeuble entier, ou un parc dans une ville. Des efforts ont également été faits pour apporter un peu de réalisme par l'ajout de vue en trois dimensions pour certains bâtiments. Mais là encore, il s'agit d'éléments purement graphiques, dépourvus d'interaction. Dans tous les cas, la personnalisation est minimaliste, sinon existante. 3042620 2 En réponse à ces problèmes, la Demanderesse a développé un dispositif et un procédé ayant fait l'objet des demandes de brevet FR 1555807 et FR 1556682. Ce type de dispositif, comme d'autres dès qu'il est fait intensément appel aux ressources Web (ce qui est souvent le cas dès que de la 3D est prévue), est très exigeant en termes de 5 ressources, et l'optimisation de l'expérience utilisateur est complexe si l'on veut l'exploiter au maximum. L'invention vient améliorer la situation. À cet effet, l'invention propose un dispositif interactif comprenant une interface utilisateur agencée pour définir au moins une 10 requête d'affichage comprenant au moins des données de localisation et des données d'affichage, une interface réseau agencée pour émettre une requête de données de page Web en correspondance d'une requête d'affichage, une mémoire pour recevoir des données de page Web correspondantes et des données de personnalisation, les données de pages Web comprenant des données de cartographie et/ou des données d'objet. 15 Le dispositif comprend en outre un interpréteur Web agencé pour permettre l'affichage une page Web et comprenant un moteur 3D agencé pour calculer des données d'affichage en trois dimensions à partir de données d'objet et un moteur d'affichage agencé pour permettre d'afficher des données de page Web à partir de données de 20 cartographie et/ou de données d'affichage en trois dimensions. L'interpréteur Web comprend en outre un gestionnaire fonctionnant par cycle d'exécution et agencé pour déterminer une liste comprenant au moins une opération pouvant être une requête de données d'objet et/ou de données de cartographie ou un 25 traitement par le moteur 3D ou le moteur d'affichage de données reçues, le gestionnaire modifiant certaines opérations de la liste d'exécution en fonction des données de personnalisation définies par l'interface utilisateur. Ce dispositif est particulièrement avantageux car il permet de réaliser un affichage 30 interactif et personnalisable en temps réel mettant en oeuvre une quantité potentiellement importante d'objets, y compris sur les dispositifs peu puissants. 3042620 3 Selon diverses variantes, le dispositif peut présenter une ou plusieurs des caractéristiques suivantes : - le gestionnaire modifie certaines opérations de traitement par le moteur 3D de la liste d'exécution en modifiant les données d'objet téléchargées en fonction des données de 5 personnalisation, - la modification des données d'objets comprend une opération parmi le groupe comprenant la modification des données de hauteur, la modification des données de couleur et/ou de transparence de texture, la modification des données définissant la forme de l'objet et la fusion avec d'autres données d'objet, 10 - le gestionnaire modifie certaines opérations de requête de données d'objets ou de traitement par le moteur 3D de la liste d'exécution en les écartant en fonction des données de personnalisation, - le gestionnaire est agencé pour exécuter les opérations selon leur ordre dans la liste, - le gestionnaire cherche à exécuter les opérations de requêtes de données avant les 15 opérations de traitement, et - le gestionnaire détermine entre l'exécution de deux opérations si une durée entre le temps courant et le temps du prochain cycle d'exécution est supérieure à une valeur temporelle seuil, et cesse de parcourir la liste d'opérations le cas échéant. 20 L'invention concerne également un produit de programme d'ordinateur comprenant des portions de code de programme pour mettre en oeuvre le dispositif interactif lorsque ledit programme est exécuté sur un ordinateur. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de 25 la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : - la figure 1 représente un diagramme schématique d'un dispositif selon l'invention, dans son environnement de fonctionnement, - la figure 2 représente un diagramme schématique d'une boucle de fonctionnement du 30 dispositif de la figure 1, et - la figure 3 représente un diagramme schématique d'une opération de mise à jour de la figure 2. 3042620 4 Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. 5 La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits. 10 La figure 1 représente un schéma générique d'un dispositif interactif 2 selon l'invention dans son environnement. L'exemple décrit ici trouve une application particulièrement intéressante dans le 15 domaine de la cartographie en ligne. Cependant, l'invention trouve son application dans toute situation impliquant un affichage en trois dimensions impliquant une interactivité avec l'utilisateur dans un contexte « tout serveur », ou « tout flux (streaming en anglais) », c'est-à-dire que toutes les données sont issues d'un serveur, le dispositif ne stockant rien localement (y compris le code JavaScript du moteur 3D dans l'exemple 20 décrit ici) à part du cache. Cette application est particulièrement adaptée à un usage Web, mais pourra être utilisée sous forme d'application pour smartphones par exemple, dans un format autre qu'une page Web. Dans ce cas, l'application pourra stocker les données de code du moteur 3D par exemple, mais ne visera toujours pas à stocker d'autres données que du cache, c'est-à-dire que les données stockées ne sont pas 25 persistantes. Le dispositif 2 comprend une mémoire 4, un affichage 6, une interface utilisateur 8, une interface réseau (non représentée) et un interpréteur Web 10. 30 La mémoire 4 peut être tout moyen de stocker des informations : de la mémoire Flash, de la mémoire RAM, un disque dur, une connexion à un stockage déporté ou dans le cloud, etc. Dans le cadre de l'invention, la mémoire 4 sert à stocker les données en vue 3042620 5 du traitement. Comme mentionné plus haut, les données de la mémoire 4 n'ont pas vocation à être persistantes, sauf à servir de cache dont la durée de validité est programmée et limitée. En effet, l'invention vise une application temps réel où toutes les données sont obtenues du serveur, sans stockage local préalable. 5 L'affichage 6 peut être tout affichage classique du type écran, projecteur vidéo, lunettes à projection, etc. L'interface utilisateur 8 permet à l'utilisateur du dispositif 2 de choisir les paramètres d'affichage de la carte ainsi que l'emplacement qu'il souhaite visualiser. 10 Les paramètres d'affichage peuvent porter de manière non restrictive sur la latitude et la longitude, le niveau de zoom, l'angle du vue, l'orientation. Ces paramètres sont classiques dans ce type d'application. L'invention propose également d'autres paramètres d'affichage, ou données de personnalisation qui seront décrites plus bas. Les données de personnalisations peuvent être définies par l'interface utilisateur de manière 15 explicite, par le choix d'options, ou implicites, par l'application de données de personnalisation associées une requête spécifique, ou encore à la manière d'un modèle ("template" en anglais). En effet, dans les applications connues, il est possible d'activer ou de désactiver 20 l'affichage de certains éléments. Cependant, il s'agit uniquement d'afficher ou de ne pas afficher les couches d'informations correspondantes. Il ne s'agit pas de permettre de personnaliser l'affichage d'un jeu restreint d'objets, par exemple. D'ailleurs, il n'est pas possible de parler « d'objets » dans les applications de l'art antérieur. Il s'agit de cartographies simples, éventuellement munies d'affichages en trois dimensions, mais 25 non individualisables. À l'inverse, l'invention permet de rendre chaque élément de la cartographie indépendant, comme objet informatique. L'interpréteur Web 10 peut être réalisé par tout navigateur mettant en oeuvre 1'HTML, le JavaScript et le WebGL. Comme on le verra dans ce qui suit, l'interpréteur Web 10 30 comprend un moteur 3D, un moteur d'affichage, un interpréteur WebGL et un gestionnaire (non représentés). Dans l'exemple décrit ici, l'utilisateur accède à la cartographie par le biais d'une page Web. Cette page Web contient à la fois du 3042620 6 code HTML, du code JavaScript et du code WebGL. Le code JavaScript définit le moteur 3D, qui reçoit des données d'objet à représenter sur la portion de carte requise par l'utilisateur, et transforme ces données d'objet en données de faces. Les données de face sont transmises à l'interpréteur WebGL qui interagit avec les ressources matérielles 5 du dispositif 2 pour calculer les données à afficher à proprement parler. L'affichage à proprement parler est géré par le moteur d'affichage de l'interpréteur Web, sur la base des données de cartographies reçues et des données d'affichage en trois dimensions calculées, comme on le verra plus bas. Le gestionnaire vient ordonnancer l'ensemble des opérations, comme cela sera décrit en référence à la figure 3. 10 Bien que dans l'exemple décrit ici l'interpréteur Web 10 utilise WebGL pour le rendu des objets en trois dimensions, l'interpréteur WebGL est optionnel et peut être remplacé par toute autre technologie appropriée. D'une manière générale, il doit être compris que le moteur 3D commande les actions nécessaires en coordination avec le gestionnaire 15 afin de calculer les données d'affichage en trois dimensions, le moteur d'affichage se chargeant uniquement de l'affichage. Comme mentionné précédemment, toutes les données sont obtenues d'un serveur 12 qui comprend une mémoire 14 et un moteur 16. La mémoire 14 est similaire à la 20 mémoire 4, sauf en ce qu'elle stocke toutes les informations utiles au fonctionnement du dispositif 2 (contrairement à la mémoire 4 qui stocke quasi-exclusivement du cache). Le moteur 16 est un élément qui reçoit les requêtes de données de pages Web du dispositif 2. Comme on l'a vu plus haut, à partir des données reçues par l'interface 25 utilisateur 8, le dispositif 2 définit une requête d'affichage de cartographie à partir des données de localisation et des données d'affichage. Ces données définissent ensemble une zone géographique. Sur la base de cette zone géographique, le dispositif 2 émet une requête de données de page Web vers le serveur 12, et le moteur 16 sélectionne dans la mémoire 14 les données de cartographie ainsi que les données des objets qui 30 correspondent à cette requête. 3042620 7 Dans l'exemple décrit ici, les données de cartographie de la mémoire 14 sont stockées sous la forme de tuiles (« tiles » en anglais) en plusieurs niveaux de détails. Ainsi, chaque tuile se décompose en quatre sous-tuiles quand le niveau de zoom augmente, et inversement, etc. Dans l'exemple décrit ici, les données de cartographie contiennent 5 pour chaque tuile la liste des objets qui lui sont associés. En variante, les données d'objets pourraient contenir des données indiquant les tuiles auxquelles ils sont rattachés. Dans l'exemple décrit ici, l'identification des tuiles est implicite, c'est-à-dire que le 10 dispositif 2 peut déterminer quelles sont les données de tuile à demander au serveur 12 via la requête de données de page Web. Ainsi, cette dernière est une pure requête de ressources, et le serveur 12 ne développe aucune « intelligence ». En variante, la requête de données de page Web pourrait être plus abstraite et contenir les données de localisation et les données d'affichage, et le serveur 12 se chargerait via le moteur 16 de 15 déterminer les données de tuile pertinentes. Les données des objets comprennent, dans l'exemple décrit ici, des données permettant de définir de manière abstraite l'affichage tridimensionnel de ces objets. Ainsi, pour un bâtiment, les données d'objet comprennent des données définissant l'empreinte au sol, 20 la forme de son toit, et des données de hauteur de bâtiment. Un même bâtiment peut présenter plusieurs hauteurs. Ainsi, lorsque le moteur 3D calcule les données de face d'un bâtiment, il procède en « élevant » un contour correspondant à l'empreinte du bâtiment au sol à la hauteur des données d'objet correspondantes, et en calculant les triangles définissant chacune des faces de l'objet ainsi défini. Une autre manière de voir 25 cela est de considérer qu'un bâtiment est « extrudé » à travers son empreinte au sol sur ses hauteurs. Pour un sol ou un relief, il est procédé de manière similaire : à partir des tuiles des données de cartographie, un maillage du sol par triangulation est réalisé. Ce maillage peut être utilisé pour représenter des reliefs grâce à des données d'objet de type données de relief, qui comprennent des données de localisation permettant 30 d'indiquer la tuile auxquelles elles correspondent, et des données d'altitude pour indiquer la hauteur du relief. Lorsque des données de relief sont reçues, les sommets des triangles des tuiles correspondants aux données de localisation correspondantes sont 3042620 8 élevés à la hauteur désignée par les données d'altitude correspondantes. Les objets peuvent également être immatériels, et désigner par exemple une ligne de bus ou de métro, ou un réseau de distribution d'eau ou d'électricité etc. De plus, comme on le verra plus bas, la manière de générer les objets peut varier selon les données de 5 personnalisation. De manière avantageuse, mais optionnelle, en fonction de la requête de données de page Web, le moteur 16 peut sélectionner les données d'objets en fonction d'une valeur indiquant leur taille. Ainsi, si le zoom est très lointain, le moteur 16 ne retourne que les 10 détails dont la taille est pertinente compte tenu de la résolution de la carte reproduite. Et dès qu'un utilisateur zoome, le moteur 16 enverra les données d'objet dont la taille les a rendus pertinents compte tenu de la résolution recherchée ou des données de personnalisation. Cela présente l'avantage de permettre de contrôler la charge de téléchargement et de traitement côté dispositif, mais également d'améliorer l'expérience 15 visuelle : au fur et à mesure qu'un utilisateur zoome, le monde se précise sous ses yeux. La figure 2 représente un diagramme schématique d'une boucle de fonctionnement du dispositif de la figure 1. 20 Dans une opération 200, le dispositif 2 réalise l'initialisation de l'affichage de la cartographie. Pour cela, les données de localisation et les paramètres d'affichage sont obtenus à partir de l'interface utilisateur 8, et le dispositif 2 met en oeuvre l'interface réseau pour émettre une requête d'affichage vers le serveur 12 avec ces données. En réponse, le serveur 12 émet des données comprenant le code du moteur 3D, ainsi que les 25 données de cartographie et les données d'objet correspondantes. Dans les échanges suivants, le code du moteur 3D n'est plus transmis, sauf pour d'éventuelles mises à jour. Dans une opération 220, le dispositif 2 reçoit les données de cartographie et les données d'objet, ainsi que le code du moteur 3D. Sur la base de ces données, l'interpréteur 30 Web 10 affiche par exemple en priorité les données de cartographies, qui donnent à l'utilisateur une vue rapide du « fond de carte ». Dans le même temps, le moteur 3D traite les données d'objet pour calculer les données de face correspondantes selon les 3042620 9 données de personnalisation. Les données de faces de chaque objet sont regroupées, et entrées dans un bloc de données de face, au moyen d'un bloc mémoire de type tableau à valeurs sur 32-bits (en anglais « Float32Array ») utilisé par l'interface WebGL, ci-après Buffer32. Le Buffer32 est un outil classique en WebGL qui sert à transmettre une 5 requête de calcul de données d'affichage 3D à une ressource matérielle à partir de données de faces définies dans le Buffer32. L'interpréteur WebGL transmet le Buffer32 contenant toutes les données de face à la ressource matérielle du dispositif 2 pour calcul des données pour l'affichage en trois dimensions des données d'objet. Chaque Buffer32 peut contenir des données relatives à 65536 sommets de triangles. Lorsqu'un Buffer32 10 est « rempli », le moteur 3D en instancie un autre, tout en préservant les correspondances entre les données de chaque Buffer32 et les objets auxquels elles correspondent. En variante, le Buffer32 pourrait être réalisé avec un autre type de tableau de valeurs. Les données de face peuvent comprendre des données définissant des sommets, des faces, ou encore des informations de mapping de texture sur les 15 triangles. Simultanément, l'interpréteur Web 10 conserve une correspondance entre les données de face regroupées pour chaque objet du Buffer32, éventuellement modifiées en fonctions des données de personnalisation, et les identifiants des objets correspondants. 20 Ainsi, si un utilisateur veut sélectionner un objet, il clique avec la souris sur un emplacement de ce dernier à l'écran (ou un autre moyen de désignation d'un emplacement à l'écran comme l' évènement « onMouseOver » JavaScript). En réponse, l'interpréteur WebGL émet une requête de type rayon (« ray picking » en anglais), qui retourne la face dans le Buffer32 qui a été désignée par le clic, et, sur la base de cette 25 correspondance, l'interpréteur Web 10 est capable de savoir quel objet a été cliqué ou désigné, et d'offrir à l'utilisateur un menu d'options pour réaliser des requêtes spécifiques à cet objet ou à une classe d'objets lui correspondant auprès du serveur 12, ou encore afficher cet objet de manière particulière. En variante, d'autres méthodes que le ray picking pourraient être utilisées pour déterminer la face qui se trouve sous la 30 souris (par exemple le rendu en un seul point de la scène avec colorisation des faces sur la base de leur identifiant et identification de la face à partir de la couleur de ce point). Les données de personnalisation et les traitements qui en découlent produisent une 3042620 10 correspondance entre les données de face regroupées pour chaque objet du Buffer32 et les identifiants des objets correspondants spécifique, de sorte que tous les objets affichés restent sélectionnables, qu'ils fassent l'objet d'une personnalisation ou pas. 5 Cette caractéristique est fondamentale pour deux raisons : - la concaténation d'un ensemble considérable de données de face dans quelques Buffer32 permet de réaliser un affichage d'une grande quantité d'objets sans perdre en fluidité ; et - le maintien de la correspondance entre les objets et les données de face qui leur 10 correspondent dans le bloc de données de face permet de rendre les objets réellement interactifs. Avant, les prétendus « objets » étaient des points ponctuels, ou des images en trois dimensions non cliquables. Dans le cas des points, il était difficile de cliquer, et la zone 15 cliquable était sans rapport avec l'objet concerné. De plus, du fait de l'approche « couche de données superposée » associée, l'idée n'était pas de rendre les objets interactifs, mais de rajouter une couche d'information simpliste. L'invention permet au contraire de produire un nouveau type de carte personnalisable 20 dans laquelle l'interaction est possible et intuitive : si l'on veut avoir un renseignement sur une ligne de métro ou sur un bâtiment, ou sur la végétation d'une rue, il suffit de cliquer n'importe où sur l'objet correspondant, même s'il a été construit sur mesure suite à une personnalisation. Cette personnalisation est de plus possible en temps réel, objet par objet, et cela quasi instantanément, car réalisée au sein de l'interpréteur web, 25 sans faire appel aux serveurs de données. Dans les cartes existantes, la plupart des détails étaient omis pour la seule raison qu'ils représentaient une masse d'information impossible à traiter d'un bloc sans ralentir de manière excessive le téléchargement et/ou l'affichage. Grâce au passage au contexte 30 « objet », les détails sont eux-mêmes des objets. Il est donc possible de choisir la priorité d'affichage des objets, les détails les plus précis, ou « moins utiles » pouvant 3042620 11 être affichés en dernier, ou ne pas être affichés du tout, ou encore être affichés plus simplement, notamment d'après les données de personnalisation. De plus, le fait de transformer la carte, d'une collection de tuiles de fonds de carte 5 juxtaposées, en un monde composé d'objets individuels génère une quantité conséquente de nouvelles applications inenvisageables précédemment. Par exemple, il devient possible de réaliser des applications immobilières ou de géolocalisation qui fournissent une information rapide et pertinente. Dans ce dernier cas, on peut imaginer qu'un clic sur un hôpital permettra de connaître les spécialités qui y sont pratiquées, ou 10 encore qu'un clic sur un bâtiment particulier indiquera quels soins particuliers sont dispensés et/ou les chambres du ou des services concernés, de cliquer sur un banc particulier pour indiquer qu'il a été vandalisé etc. Et les autres détails environnants peuvent être priorisés de manière inférieure pour préserver l'expérience utilisateur en lui fournissant l'information qui l'intéresse en priorité (personnalisation). Il devient donc 15 possible d'introduire une quantité énorme de « couches d'informations » de manière simple dans des cartes, là où cela était précédemment impossible ou incommode du fait de l'utilisation de « layers » superposées et non directement liées à des objets individualisés et de produire en temps réel des cartes intégralement personnalisées par utilisateur et instant d'utilisation. 20 Enfin, dans une opération 240, le dispositif 2 met à jour l'affichage 6 en fonction des entrées utilisateur via l'interface utilisateur 8. Ainsi, si l'utilisateur change de niveau de zoom, déplace la carte ou interagit avec l'un des objets, l'interpréteur Web 10 appelle le serveur 12 pour obtenir de nouvelles données et calcule les données modifiées en 25 conséquence. Les opérations 220 et 240 sont réalisées en tenant compte de données de personnalisations génériques ou spécifiées par l'utilisateur. En effet, le dispositif de l'invention permet de définir des critères de personnalisation de l'affichage. 30 3042620 12 Ces critères permettent de rendre l'affichage de l'invention compatible avec des dispositifs peu puissants, en réduisant le nombre d'objets devant être affichés, ou au contraire d'enrichir encore la qualité de reproduction avec des dispositifs plus puissants. 5 Ainsi, sur une application de type localisation, l'utilisateur pourra voir la carte se personnaliser pour lui selon les recherches qu'il effectue. Par exemple, s'il cherche un théâtre, l'intégralité du bâtiment contenant le théâtre sera mis en valeur, par exemple en étant affiché en rouge, à la place du classique marqueur 10 au-dessus du bâtiment. De plus, il sera possible également de mettre en valeur les restaurants ouverts et autour du théâtre. Selon que l'utilisateur possède une voiture, qu'il préfère les transports en commun ou la bicyclette, les parkings autour du théâtre, les lignes et arrêts ou les pistes cyclables pourront être mis en valeur. 15 En variante, la personnalisation pourra être une modification lors du traitement des données d'objet, par : - changement de couleur, soit données de face par données face, ou encore objet par objet (toit, mur, etc.), - changement de hauteur, pour réduire celle des immeubles ou objets qui ne sont pas 20 pertinents au vu des données de personnalisation, ou pour augmenter la taille de certains objets qui le sont, - simplification des objets qui ne sont pas pertinents au vu des données de personnalisation, par exemple par fusion d'immeubles contigus en un seul pâté de maisons, par génération de surfaces triangulées représentant une forêt plutôt que des 25 arbres individuels, par diminution du niveau de détail de certains objets, - non affichage de textures associées à des objets non pertinents au vu des données de personnalisation, ou utilisation de modèles par défaut à la place de certains objets (par exemple, un arbre peut être stylisé sous forme d'une boule). 30 Certaines de ces mises en valeur permettent d'économiser une puissance de calcul importante, et de rendre l'application plus fluide et plus claire pour l'utilisateur. De plus, comme la personnalisation est réalisée sur le dispositif, le serveur qui contient les 3042620 13 données d'objets peut offrir la totalité des expériences possibles à tous les utilisateurs avec une seule version des données. Cela est donc également plus économique côté serveur. 5 La figure 3 représente un exemple de mise en oeuvre des opérations 220 et 240. En effet, le dispositif de l'invention permet d'afficher un monde présentant une richesse inégalée. Comme on vient de le voir, cette richesse est rendue en partie possible grâce à la réalisation de calculs sur le dispositif, par exemple pour calculer les données de face des objets. 10 Malgré toutes les optimisations offertes par l'invention, il va de soi que, si le dispositif attend de disposer de toutes les données pour afficher la carte, tant à l'initialisation que lors d'un changement important de position, le délai d'affichage risque d'être très important, et l'expérience utilisateur en souffrira. 15 Cela est d'autant plus important que les navigateurs Web et autres dispositifs embarquant un interpréteur Web sont limités dans le nombre de requêtes simultanées qu'ils sont capables d'émettre. En effet, ils peuvent émettre en général entre 25 et 50 requêtes d'obtention de données de pages Web en simultané, sans que ce nombre soit 20 par ailleurs connu ou standardisé. Lorsque l'on considère cette limitation au vu du dispositif décrit ci-dessus, il apparaît assez rapidement que, au moins dans la phase d'initialisation de la carte, le dispositif va rapidement saturer le nombre de requêtes de données de pages Web, et que cette 25 saturation dépendra d'un facteur qui ne peut pas être maîtrisé. Une solution doit donc être trouvée pour permettre de conserver une bonne expérience utilisateur dans un environnement complexe comme celui du dispositif décrit ci-dessus, qui fait appel à de très nombreuses ressources Web. 30 Pour cela, la Demanderesse a développé le gestionnaire de l'interpréteur Web. Ce gestionnaire a pour rôle la sélection des objets à afficher, leur modification éventuelle en fonction des données de personnalisation, ainsi que l'ordonnancement des opérations 3042620 14 afin d'optimiser l'expérience utilisateur. Dans l'exemple qui est décrit ici, il est considéré qu'un affichage à 60 images par seconde est optimal, et le gestionnaire est optimisé en ce sens. Dans d'autres variantes, selon d'autres critères, le gestionnaire pourra être agencé différemment. 5 Le gestionnaire organise donc les opérations au sein de l'interpréteur Web. Pour cela, il gère deux types d'opérations : les requêtes de données, et les traitements de données. Les requêtes de données sont toute requête de données de pages Web, qu'elle concerne des données de cartographie ou des données d'objet ou des données de mise à jour du 10 code du moteur 3D. D'une manière générale, ces requêtes peuvent donc être vues comme tout échange entre le dispositif et l'extérieur, et qui peuvent donc saturer comme expliqué plus haut. À l'inverse, les traitements de données concernent toutes les opérations qui sont internes 15 au dispositif, comme par exemple, la triangulation de données d'objets pour obtenir des données de face, leur rangement dans des données de bloc de face, la transmission de données de bloc de faces à l'interpréteur WebGL pour le calcul des données d'affichage en trois dimensions, etc. 20 Il faut aussi comprendre que les requêtes de données et les traitements de données ne sont pas indépendants : un traitement de données est directement ou indirectement lié à une requête de données qui s'est achevée. Le dispositif fonctionne donc par cycles d'exécution. Au sein d'un cycle d'exécution 25 donné, le gestionnaire détermine la liste des opérations « en cours », c'est-à-dire à réaliser, et choisit celles de ces opérations qui vont être exécutées pour ce cycle. Le téléchargement de nouvelles données est réalisé en priorité, puisque ce sont ces données qui une fois téléchargées sont traitées pour être affichées. Cela est d'autant plus important que, si le temps de traitement des données est relativement prévisible (car 30 dépendant de ressources locales), les temps de téléchargement le sont moins (les réseaux pouvant présenter une latence incontrôlable). 3042620 15 Sur le principe, pour un cycle d'exécution donné, le gestionnaire va lancer en priorité les requêtes de données nouvellement générées et les requêtes de données non lancées dans le ou les cycles précédents. Ensuite, une fois que toutes les demandes de téléchargement possibles ont été lancées, le gestionnaire alloue du temps aux opérations 5 de traitement des données reçues. Dans l'exemple décrit ici, la situation est encore un peu plus complexe, car le gestionnaire va gérer plusieurs listes d'opérations en fonction de leur priorité qui peut aussi dépendre des données de personnalisation. Par exemple, une opération portant sur 10 une tuile de fond de carte aura priorité sur une opération de détail. Pour cela, le gestionnaire gère plusieurs listes, qu'il cherche à vider les unes après les autres. Ainsi, le gestionnaire va d'abord lancer toutes les requêtes de données de la première liste (dans la limite de la quantité possible simultanément), puis tous les traitements de données de la première liste, puis une fois qu'il aura épuisé cette première liste, il 15 passera à la deuxième liste etc. Le gestionnaire part donc, pour un cycle donné d'une opération 300 à partir d'un tableau d'opérations (requête ou traitement) à exécuter OP[], d'un indice i de priorité de liste initialisé à 0, et un tableau de traitements à exécuter PR[], lui aussi initialisé à 0. 20 Dans une opération 305, une fonction Tick() vérifie si un nouveau cycle d'exécution est si proche qu'aucune nouvelle opération ne peut être lancée. Si c'est le cas, alors l'opération 305 se répète jusqu'à ce que nouveau cycle commence. 25 Si ce n'est pas le cas, alors dans une opération optionnelle 310, le gestionnaire peut tenir compte d' évènements externes pour modifier son fonctionnement avec une fonction Chng(). Par exemple, si l'utilisateur se met à se déplacer avec vitesse dans la carte, le 30 gestionnaire pourra changer les listes de priorité (par exemple, ne plus charger les détails, rendre plus prioritaires des données de tuile qui étaient auparavant en bord d'image et qui deviennent centrales compte tenu du déplacement), abandonner certaines 3042620 16 opérations qui ne sont plus pertinentes (par exemple, une requête pour une tuile qui ne sera plus affichée compte tenu de la direction de déplacement, modifier la durée de cycle pour tenir compte d'informations entrées par l'utilisateur (qui peut privilégier plus de détails ou au contraire privilégier une parfaire fluidité, etc.), etc. 5 Ensuite, deux boucles commencent dans lesquelles le tableau d'opérations OP[] d'indice i va être progressivement dépilé pour lancer l'exécution des requêtes de données (première boucle), avant de lancer l'exécution des traitements de données (deuxième boucle). Dans ce qui suit, on parlera indifféremment de tableau OP[] 10 d'indice i ou de liste OP[i], le tableau étant uniquement une manière de mettre en oeuvre les listes de priorités différentes. Lorsque ces deux boucles sont terminées sans que le cycle d'exécution se termine, l'opération 305 reprend avec la liste de priorité suivante. La première boucle commence avec une opération 315 par le dépilage d'une opération x 15 courante de la liste OP[i]. Dans une opération 320, une fonction Req() détermine si l'opération x est une requête, et si le nombre maximal de requêtes simultanées est atteint ou non. S'il s'agit d'une requête et que le nombre de requêtes simultanées n'est pas atteint, alors 20 dans une opération 325, une fonction Proc() analyse l'objet concerné et détermine si cet objet correspond aux données de personnalisation. Si ce n'est pas le cas, alors la requête est effacée et la fonction Proc() se termine. Sinon, la fonction Proc() lance l'exécution de la requête de données. Dès que le téléchargement des données correspondantes est réalisé, l'interpréteur Web modifie la liste d'opérations en conséquence pour introduire 25 une opération de traitement de données relatives aux données téléchargées. S'il ne s'agit pas d'une requête, ou si le nombre de requêtes simultanées est atteint, alors dans une opération 330, le gestionnaire exécute une fonction Push() qui analyse l'opération x et, s'il s'agit d'un traitement de données, l'introduit dans la liste PR[i] des 30 traitements à effectuer. S'il s'agit d'une requête et que le nombre de requêtes simultanées est pas atteint, alors la fonction Push() déplace l'opération x dans la liste des opérations à traiter dans le cycle d'exécution suivant. 3042620 17 Enfin, après l'opération 325 ou l'opération 330, une fonction Stop() 335 détermine si le gestionnaire peut encore initialiser de nouvelles tâches ou non. Si ce n'est pas le cas, alors l'indice i est réinitialisé à 0 dans une opération 340, et le prochain cycle d'exécution est attendu avec l'opération 305. Si c'est le cas, alors la première boucle 5 reprend avec l'opération 320 pour dépiler l'opération suivante de la liste de priorité d'indice i. Lorsque la liste d'opérations d'indice i (OP[i]) est vide, la deuxième boucle commence. Dans cette deuxième boucle, la liste PR[i] va être dépilée pour exécuter les opérations 10 de traitement, d'une manière similaire à la première boucle, mais elle est plus simple car par construction, la liste PR[i] ne contient que des opérations de traitement. Ainsi, dans une opération 345, la liste PR[i] est dépilée, et dans une opération 350, la fonction Proc() est à nouveau appelée pour exécuter le traitement x courant. De la même 15 manière que pour l'opération 325, la fonction Proc() commence par vérifier si le traitement x est encore compatible avec les données de personnalisation. Si ce n'est pas le cas, alors la requête est effacée et la fonction Proc() se termine. Sinon, la fonction Proc() lance l'exécution du traitement. L'exécution de ce traitement peut varier en fonction des données de personnalisation. 20 Par exemple, si les données de personnalisation changent la hauteur d'un bâtiment pour le mettre en valeur, le traitement constituera à faire calculer les données de face correspondantes, avec la hauteur modifiées selon les données de personnalisation. Si les données de personnalisation indiquent qu'un objet doit être représenté par une boule, 25 alors le traitement constituera à calculer les données de face d'une boule, adaptée selon les dimensions de l'objet. Si les données de personnalisation modifient la couleur ou la transparence de la texture d'une face, alors le traitement inclura le calcul des données de face avec la modification de la texture, etc. 30 Pour cela, l'interpréteur Web instancie un Web Worker, qui est un composant Javascript qui permet de tirer parti de l'architecture multi-coeurs des processeurs modernes. En variante, l'interpréteur Web peut fonctionner sans Web Worker, et la fonction Proc() 3042620 18 peut réaliser un autre traitement de personnalisation comme décrit en référence à la figure 2. Ensuite, dans une opération 355, la fonction Stop() est relancée de la même manière que 5 l'opération 335. Lorsque l'opération 335 indique une fin de cycle d'exécution la deuxième boucle se termine avec l'opération 340 puis l'attente du cycle d'exécution suivant avec l'opération 305. Sinon, la deuxième boucle se poursuit avec l'opération 345 jusqu'à ce que la liste PR[i] soit vide ou que la fonction Stop() indique une fin de cycle d'exécution. 10 Lorsque la liste PR[i] est vide, alors le gestionnaire peut passer à la liste de priorité suivante, en incrémentant l'indice i dans une opération 360, et en vérifiant sur la liste d'indice i existe dans une opération 365. Si c'est le cas, alors le cycle d'exécution se poursuit avec la première opération 320 de la première boucle de la nouvelle liste de 15 priorité. Sinon, alors l'indice i est réinitialisé à 0 dans une opération 370, et le prochain cycle d'exécution est attendu avec l'opération 305. Le mode de fonctionnement décrit avec la figure 3 est particulièrement intéressant car il permet de tenir à jour en permanence les listes d'opérations d'un cycle d'exécution à 20 l'autre. Lorsqu'une nouvelle opération est introduite, l'interpréteur Web la transmet au gestionnaire qui la reçoit dans une des listes de priorisation et l'exécute aussi vite que possible. De plus, ce fonctionnement assure un affichage aussi rapide que possible : le moteur 25 d'affichage n'attend pas que toutes les données soient arrivées pour commencer à afficher la carte. Par la nature même de la priorisation, les données les plus importantes seront reçues en premier et affichées dès que possible. Ainsi, le monde se construit sous les yeux de l'utilisateur. 3042620 19 Par exemple, pour une utilisation dans le domaine de l'immobilier : - Liste 0 (priorité maximale) : les localisations des biens immobiliers, car il est plus important pour l'utilisateur de voir qu'il y a biens qui correspondent à ses critères de recherche quelque part sur la carte que de pouvoir se repérer, 5 - Liste 1 : le fond de carte, car il permet à l'utilisateur de se repérer, - Liste 2 : l'information définissant le relief du terrain et les bâtiments, - Liste 3 : les arbres, fontaines, vignes, cimetières... En variante, il peut n'y avoir qu'une seul liste de priorisation. Comme mentionné 10 précédemment, certains éléments peuvent voir leur priorité et/ou leur inclusion dans les listes de priorisation dépendre de leur nature. Par exemple, les objets de type « détails » peuvent ne pas être affichés lorsque le zoom indique une distance trop importante. Ainsi, dans l'exemple décrit ici, Les détails loin à l'horizon donc très petits ne sont pas demandés par le client. À chaque type de détail est associée une distance max, qui ne 15 dépend pas de sa taille uniquement. Par exemple, les pylônes à l'horizon ne sont jamais demandés, mais les forêts le sont toujours. De la même manière, la fonction Chng() peut tenir compte du fait que l'utilisateur est en train de bouger la caméra pour adapter les priorités. Ci-après, quelques exemples de 20 traitements qui peuvent être gérés par la fonction Chng(). Après chaque déplacement ou zoom demandé par l'utilisateur, l'interpréteur Web trie les demandes pour traiter en priorité les opérations en rapport avec ce qui est le plus proche du centre de l'écran car c'est l'endroit que regarde l'utilisateur. 25 Quand l'utilisateur bouge la carte, les opérations de requêtes peuvent voir leur priorité changer : - certaines opérations peuvent être désactivées, par exemple en ne traitant pas les listes les moins prioritaires par le gestionnaire (dans l'exemple immobilier décrit plus haut, 30 seules, par exemple on ne demande plus que les localisations des biens immobiliers (Liste 0) et éventuellement le fond de carte (Liste 1) 3042620 20 - le gestionnaire demande au serveur des tuiles de niveau de détail inférieur (donc présentant un contenu plus synthétique) à celle qu'il demanderait quand la carte est immobile, mais pour une utilisation à la taille supérieure : cela permet de charger de plus vite donc augmente la fluidité, et même si la carte affichée est moins précise donc 5 moins nette, le mouvement fera que l'utilisateur ne s'en rendra pas compte, - les demandes de tuiles pour lesquelles aucunes données n'ont encore été reçues voient leur priorité être augmentée par rapport aux tuiles pour lesquelles des données sont déjà disponibles mais dans un niveau de détail inférieur au niveau demandé. - toute opération qui concerne quelque chose qui n'est plus visible par l'utilisateur est 10 annulée, donc supprimée de la liste de priorisation. Par ailleurs, une tuile affichée sera gardée en cache, jusqu'à ce que le centre de la carte soit à une distance choisie de cette tuile (par exemple 10 km). 15 Les opérations de traitement peuvent également voir leur priorité changer : - quand la carte bouge, le gestionnaire diminue le temps accordé à la génération des détails et des bâtiments, qui vont ainsi apparaître plus tard sans provoquer de saccades dans le mouvement, - si le gestionnaire détermine que le dispositif n'est pas assez puissant pour réaliser tous 20 les traitements, certains objets peuvent être sélectivement désactivés, comme des objets de décoration (la texture et l'animation de l'eau des cours d'eau, etc.), en fonction des données de personnalisation, - les traitements des données de bloc de données de faces peuvent être rendus prioritaires par rapport aux traitements des données de textures pour leur envoi aux 25 ressources matérielles de calcul. Dans ce qui précède, l'invention a été décrite dans sa forme la plus aboutie, c'est-à-dire avec l'utilisation du Buffer32, la personnalisation et l'ordonnancement des opérations. Cependant, la seule utilisation des données de personnalisation permettrait de mettre en 30 oeuvre l'invention sur des dispositifs plus simples, par exemple ne mettant en oeuvre ni le Buffer32, ni l'ordonnancement des opérations. 3042620 21 En effet, dans un dispositif classique, l'affichage de tous les objets serait impossible à réaliser tout en ayant un affichage suffisamment fluide et détaillé. L'invention, en sélectionnant un ensemble restreint et optimisé d'objets à afficher d'après les données de personnalisation, permet au contraire d'obtenir des résultats satisfaisants, tout en 5 offrant la variété optimale d'affichage à tous les utilisateurs, du fait que la personnalisation est réalisée sur le dispositif, et non pas sur le serveur. Dans le même temps, l'invention permet également d'utiliser les données de personnalisation de manière optimale pour mettre en valeur l'application lorsque le 10 dispositif est du type de celui décrit plus haut. D'autres variantes pourront apparaître à la lecture des revendications qui suivent. REVENDICATIONS1. Dispositif interactif, comprenant une interface utilisateur (8) agencée pour définir au moins une requête d'affichage comprenant au moins des données de localisation et des données d'affichage, une interface réseau agencée pour émettre une requête de données de page Web en correspondance d'une requête d'affichage, une mémoire (4) pour recevoir des données de page Web correspondantes et des données de personnalisation, les données de pages Web comprenant des données de cartographie et/ou des données d'objet, le dispositif (2) comprenant en outre un interpréteur Web (10) agencé pour permettre l'affichage une page Web et comprenant un moteur 3D agencé pour calculer des données d'affichage en trois dimensions à partir de données d'objet et un moteur d'affichage agencé pour permettre d'afficher des données de page Web à partir de données de cartographie et/ou de données d'affichage en trois dimensions, l'interpréteur Web (10) comprenant en outre un gestionnaire fonctionnant par cycle d'exécution et agencé pour déterminer une liste comprenant au moins une opération pouvant être une requête de données d'objet et/ou de données de cartographie ou un traitement par le moteur 3D ou le moteur d'affichage de données reçues, le gestionnaire modifiant certaines opérations de la liste d'exécution en fonction des données de personnalisation définies par l'interface utilisateur. 2. Dispositif selon la revendication 1, dans lequel le gestionnaire modifie certaines opérations de traitement par le moteur 3D de la liste d'exécution en modifiant les données d'objet téléchargées en fonction des données de personnalisation. 3. Dispositif selon la revendication 2, dans lequel la modification des données d'objets comprend une opération parmi le groupe comprenant la modification des données de hauteur, la modification des données de couleur et/ou de transparence de texture, la modification des données définissant la forme de l'objet et la fusion avec d'autres données d'objet. 3042620 23 4. Dispositif selon la revendication 1 ou 2, dans lequel le gestionnaire modifie certaines opérations de requête de données d'objets ou de traitement par le moteur 3D de la liste d'exécution en les écartant en fonction des données de personnalisation. 5 5. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire est agencé pour exécuter les opérations selon leur ordre dans la liste. 6. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire 10 cherche à exécuter les opérations de requêtes de données avant les opérations de traitement. 7. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire détermine entre l'exécution de deux opérations si une durée entre le temps 15 courant et le temps du prochain cycle d'exécution est supérieure à une valeur temporelle seuil, et cesse de parcourir la liste d'opérations le cas échéant. 8. Produit de programme d'ordinateur comprenant des portions de code de programme pour mettre en oeuvre le dispositif selon l'une des revendications 20 précédentes lorsque ledit programme est exécuté sur un ordinateur.