EP3314474A1 - Dispositif interactif a affichage tridimensionnel - Google Patents

Dispositif interactif a affichage tridimensionnel

Info

Publication number
EP3314474A1
EP3314474A1 EP16742340.9A EP16742340A EP3314474A1 EP 3314474 A1 EP3314474 A1 EP 3314474A1 EP 16742340 A EP16742340 A EP 16742340A EP 3314474 A1 EP3314474 A1 EP 3314474A1
Authority
EP
European Patent Office
Prior art keywords
data
display
interpreter
face
web page
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16742340.9A
Other languages
German (de)
English (en)
Inventor
Fabrice Bernard
Ludovic PERRINE
Jean-Marc Oury
Bruno Heintz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
F4
Original Assignee
F4
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by F4 filed Critical F4
Publication of EP3314474A1 publication Critical patent/EP3314474A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3667—Display of a road map
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—Three-dimensional [3D] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three-dimensional [3D] modelling for computer graphics
    • G06T17/05—Geographic models

Definitions

  • the invention relates to web devices, and in particular devices for interaction. More particularly, the invention relates to the field of mapping on the Internet.
  • the invention proposes an interactive device, comprising a user interface for defining display requests comprising at least location data and display data, a network interface arranged to send a request for data of web pages. in correspondence with a display request, a memory for receiving corresponding web page data, and a web interpreter for displaying a web page from web page data, which web interpreter includes at least one WebGL interpreter and an engine 3D arrangement for computing, for data web page data including mapping data and object data, face data of at least one object associated with the object data, for grouping said face data into data of face blocks and transmitting the face block data to the WebGL interpreter for computing three-dimensional display data of the at least one object by keeping a correspondence between at least some of the objects associated with the object data and the corresponding face data in the face block data, the web interpreter being arranged to allow display of web page data to from the mapping data and the three-dimensional display data of the at least one object.
  • This device is advantageous because it allows to have a representation of a map in three dimensions, with as many objects in three dimensions as necessary, each object being individually clickable and allowing an unknown interaction until then.
  • the face data is calculated on the client side, it becomes possible to transmit a large quantity of objects in three dimensions, which makes it possible to model all the buildings of a city, but also the trees and other road details. , as well as networks that achieve a degree of detail and interactivity never achieved while maintaining a fluid display.
  • the device may have one or more of the following characteristics:
  • the memory stores only data of type cache
  • the display data comprises zoom data
  • the mapping data define a geographical environment substantially centered on a location designated by the location data, and the extent of which depends on the zoom data
  • the object data includes building data including building location data, roof shape data, and height data,
  • the object data comprises terrain data including location data, and altitude data
  • the 3D engine calculates the face data by triangulation from the object data and zoom data
  • the web interpreter is arranged to determine an object data identifier of an object designated by a user via the user interface from the correspondence between at least some of the objects associated with the object data and the data of the user. corresponding faces in the face block data.
  • the code of the 3D engine is received as display data at the device initialization and / or during updates
  • the 3D engine arranges the data of blocks of faces in an object of the Float32Array type
  • the device comprises material resources dedicated to the display.
  • the invention also relates to an interactive display method comprising the following operations:
  • a display request comprising at least location data and display data
  • vs. receive corresponding web page data including mapping data and object data, and transmit them to a web interpreter including a 3D engine and a WebGL interpreter
  • calculating with the 3D engine face data of at least one object associated with the object data, and grouping these face data in face block data e. transmitting the faceblock data to the WebGL interpreter, maintaining a correspondence between at least some of the objects associated with the object data and the corresponding face data in the faceblock data, for computing data three-dimensional display of said at least one object, f. calling the web interpreter with the mapping data and the three-dimensional display data of the at least one object to display web page data.
  • FIG. 1 represents a schematic diagram of a device according to the invention, in its operating environment
  • FIG. 2 represents a schematic diagram of an operating loop of the device of FIG. 1, and
  • FIG. 3 represents a schematic diagram of an updating operation of FIG. 2.
  • FIG. 1 represents a generic diagram of an interactive device 2 according to the invention in its environment.
  • the example described here finds a particularly interesting application in the field of on-line mapping.
  • the invention finds its application in any situation involving a three-dimensional display involving interactivity with the user in a context "any server", or "any flow (streaming English)", that is to say that all the data comes from a server, the device does not store anything locally (including the JavaScript code of the 3D engine in the example described here) apart from the cache.
  • This application is particularly suitable for web use, but may be used as an application for smartphones for example, in a format other than a web page. In this case, the application may store the code data of the 3D engine for example, but will still not aim to store other data than cache, that is to say, the stored data is not persistent.
  • the device 2 comprises a memory 4, a display 6, a user interface 8, a network interface (not shown) and a web interpreter 10.
  • the memory 4 can be any means of storing information: flash memory, RAM memory, a hard disk, a connection to a remote storage or in the cloud, etc.
  • the memory 4 is used to store the data for processing.
  • the data of the memory 4 are not intended to be persistent, except to serve as cache whose validity period is programmed and limited. Indeed, the invention is a real-time application where all the data are obtained from the server, without prior local storage.
  • the display 6 can be any conventional display of the screen type, video projector, projection glasses, etc.
  • the user interface 8 allows the user of the device 2 to choose the display parameters of the card and the location he wants to view.
  • the display parameters may include, but are not limited to, latitude and longitude, zoom level, viewing angle, orientation. These parameters are classic in this type of application.
  • the invention also proposes other display parameters, called "customization" parameters. Indeed, in known applications, it is possible to activate or deactivate the display of certain elements. However, this only involves displaying or not displaying the corresponding information layers. It is not a question of allowing to personalize the display of a restricted set of objects, for example. Moreover, it is not possible to speak of "objects" in the applications of the prior art. They are simple cartographies, possibly equipped with displays in three dimensions, but not individualizable. Conversely, the invention makes it possible to make each element of the map independent, as a computer object.
  • the web interpreter 10 can be realized by any browser implementing HTML, JavaScript and WebGL. As will be seen in the following, the web interpreter 10 includes a WebGL interpreter and a 3D engine (not shown). In the example described here, the user accesses the map through a web page. This web page contains both HTML code, JavaScript code and WebGL code. The JavaScript code defines the 3D engine, which receives object data to be represented on the map portion required by the user, and transforms that object data into face data. The face data is transmitted to the WebGL interpreter which interacts with the hardware resources of the device 2 to calculate the data to be displayed as such.
  • a server 12 which comprises a memory 14 and a motor 16.
  • the memory 14 is similar to the memory 4, except that it stores all the information useful for the operation of the device 2 (unlike the memory 4 which stores almost exclusively cache).
  • the engine 16 is an element that receives the requests for data from Web pages of the device 2. As seen above, from the data received by the user interface 8, the device 2 defines a request for displaying the mapping from location data and display data. These data together define a geographical area. Based on this geographic area, the device 2 issues a web page data request to the server 12, and the engine 16 selects in the memory 14 the mapping data as well as the data of the objects that correspond to this query.
  • the mapping data of the memory 14 are stored in the form of tiles ("tiles" in English) in several levels of detail. Thus, each tile breaks down into four sub-tiles when the zoom level increases, and vice versa, and so on.
  • the mapping data contains for each tile the list of objects associated with it.
  • the object data could contain data indicating the tiles to which they are attached.
  • the identification of the tiles is implicit, ie the device 2 can determine which tile data to request from the server 12 via the web page data request.
  • the latter is a pure resource request, and the server 12 does not develop any "intelligence".
  • the web page data request could be more abstract and contain the location data and the display data, and the server 12 would load via the engine 16 to determine the relevant tile data.
  • the data of the objects comprise, in the example described here, data enabling the three-dimensional display of these objects to be defined in an abstract manner.
  • the object data includes data defining the footprint, the shape of its roof, and building height data.
  • a building can have several heights.
  • the 3D engine calculates the face data of a building, it proceeds by "raising" an outline corresponding to the footprint of the building on the ground to the height of the corresponding object data, and calculating the triangles defining each faces of the object thus defined. Another way of looking at this is to consider that a building is "extruded" through its footprint on its height.
  • a mesh of the ground by triangulation is realized.
  • This mesh can be used to represent reliefs by means of object data of the relief data type, which includes location data enabling to indicate the tile to which they correspond, and altitude data to indicate the height of the relief.
  • object data of the relief data type which includes location data enabling to indicate the tile to which they correspond
  • altitude data to indicate the height of the relief.
  • Objects can also be immaterial, such as a bus or metro line, or a water or electricity distribution network.
  • the engine 16 may select the object data based on a value indicating their size.
  • the engine 16 only returns details whose size is relevant given the resolution of the reproduced card.
  • the engine 16 will send object data whose size has made them relevant given the desired resolution. This has the advantage of controlling the download and processing load on the device side, but also improving the visual experience: as a user zooms in, the world becomes clearer.
  • FIG. 2 represents a schematic diagram of an operating loop of the device of FIG. 1.
  • the device 2 initializes the display of the map. For this, the location data and the display parameters are obtained from the user interface 8, and the device 2 implements the network interface to issue a display request to the server 12 with these data. In response, the server 12 transmits data including the code of the 3D engine, as well as the mapping data and the corresponding object data. In subsequent exchanges, the 3D engine code is no longer transmitted.
  • the device 2 receives the mapping data and the object data, as well as the code of the 3D engine.
  • the web interpreter 10 displays, for example, the mapping data first, which gives the user a quick view of the "basemap".
  • the 3D engine processes the object data to calculate the corresponding face data.
  • the face data of each object is grouped and entered in a face data block by means of a 32-bit array ("Float32Array") type of memory block used by the WebGL interface. hereinafter Buffer32.
  • the Buffer32 is a classic WebGL tool used to send a 3D display data calculation request to a hardware resource from face data defined in the Buffer32.
  • the WebGL interpreter transmits the Buffer32 containing all the data from the face to the hardware resource of the device 2 for computing the data for the three-dimensional display of the object data.
  • Each Buffer32 can contain data related to 65536 triangle vertices. When a Buffer32 is "full", the 3D engine instantiates another one, while preserving the correspondences between the data of each Buffer32 and the objects to which they correspond. Alternatively, Buffer32 could be realized with another type of array of values.
  • the face data may include data defining vertices, faces, or texture mapping information on the triangles.
  • the web interpreter 10 maintains a correspondence between the grouped front data for each object of the Buffer32 and the identifiers of the corresponding objects.
  • a user wants to select an object, he clicks with a mouse on a location on the screen (or other means of naming a location on the screen as the event "onMouseOver” JavaScript).
  • the WebGL interpreter issues a ray picking request, which returns the face in the Buffer32 that has been designated by the click, and, based on this match, the Web interpreter 10 is able to know which object has been clicked or designated, and to offer the user a menu of options for making specific requests to this object or to a class of objects corresponding to the server 12, or display this object in a particular way.
  • other methods than ray picking could be used to determine the face that is under the mouse (eg the single-point rendering of the scene with colorization of the faces based on their identifier and identification of the face from the color of this point).
  • the invention makes it possible to produce a new type of card in which the interaction is possible and intuitive: if one wants to have information on a metro line or a building, or on the vegetation of a street, just click anywhere on the corresponding object.
  • the device 2 updates the display 6 according to the user inputs via the user interface 8.
  • the web interpreter 10 calls the server 12 to obtain new data and calculates the modified data accordingly.
  • FIG. 3 represents an exemplary implementation of the operation 240.
  • the web interpreter 10 determines the location data associated with the center of the card designated by the user interface 8. Then, the interpreter Web 10 determines the display settings such as viewing angle and zoom to determine a new area to be represented by the display.
  • the web interpreter 10 determines the list of tiles corresponding to the new view determined in the operation 300 and asks the server only those that it does not already have. In response, the server 12 returns the list of corresponding tiles.
  • the server 12 can keep a list of tiles and objects already transmitted and / or considered current, and directly transmit new relevant data.
  • the web interpreter 10 carries out the same operations as for the operation 220 for the newly obtained data, and updates, if necessary, the data already known and displayed.
  • Updating the altitude of a building already displayed can be performed by simply updating the elevation in the definition of building face data in the face data block.
  • the update is as light as possible and allows the construction of a 3D map with data arriving only sequentially and in disorder.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Remote Sensing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Data Mining & Analysis (AREA)
  • Geometry (AREA)
  • Computer Graphics (AREA)
  • Software Systems (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Processing Or Creating Images (AREA)
  • Instructional Devices (AREA)

Abstract

Un dispositif interactif comprend une interface utilisateur (8) pour définir des requêtes 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 pages Web en correspondance d'une requête d'affichage, une mémoire (4) pour recevoir des données de page Web correspondantes, et un interpréteur Web (10) pour afficher une page Web à partir de données de page Web. L'interpréteur Web(10) comprend au moins un interpréteur WebGL et un moteur3D agencé pour calculer, pour des données de page Web données comprenant des données de cartographie et des données d'objet, des données de faces d'au moins un objet associé aux données d'objet, pour regrouper ces données de faces dans des données de blocs de face et transmettre les données de blocs de faces à l'interpréteur WebGL pour le calcul de données d'affichage en trois dimensions dudit au moins un objet en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face. L'interpréteur Web (10) est agencé pour permettre d'afficher des données de page Web à partir des données de cartographie et des données d'affichage en trois dimensions des objets.

Description

Dispositif interactif à affichage tridimensionnel
L'invention concerne les 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. L'invention vient améliorer la situation. À cet effet, l'invention propose un dispositif interactif, comprenant une interface utilisateur pour définir des requêtes 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 pages Web en correspondance d'une requête d'affichage, une mémoire pour recevoir des données de page Web correspondantes, et un interpréteur Web pour afficher une page Web à partir de données de page Web, lequel interpréteur Web comprend au moins un interpréteur WebGL et un moteur 3D agencé pour calculer, pour des données de page Web données comprenant des données de cartographie et des données d'objet, des données de faces d'au moins un objet associé aux données d'objet, pour regrouper ces données de faces dans des données de blocs de face et transmettre les données de blocs de faces à l'interpréteur WebGL pour le calcul de données d'affichage en trois dimensions dudit au moins un objet en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, l'interpréteur Web étant agencé pour permettre d'afficher des données de page Web à partir des données de cartographie et des données d'affichage en trois dimensions dudit au moins un objet.
Ce dispositif est avantageux car il permet d'avoir une représentation d'une cartographie en trois dimensions, avec autant d'objets en trois dimensions que nécessaire, chaque objet étant cliquable individuellement et permettant une interaction inconnue jusqu'alors. De plus, comme les données de face sont calculées côté client, il devient possible de transmettre une grande quantité d'objets en trois dimensions, ce qui permet de modéliser tous les immeubles d'une ville, mais également les arbres et autres détails de voirie, ainsi que les réseaux qui permettent d'atteindre un degré de détail et d'interactivité jamais atteint tout en conservant un affichage fluide.
Selon diverses variantes, le dispositif peut présenter une ou plusieurs des caractéristiques suivantes :
- la mémoire stocke uniquement des données de type cache, - les données d'affichage comprennent des données de zoom, et les données de cartographie définissent un environnement géographique sensiblement centré sur un endroit désigné par les données de localisation, et dont l'étendue dépend des données de zoom,
- les données d'objet comprennent des données de bâtiment comprenant des données de localisation de bâtiment, des données de forme de toit, et des données de hauteur,
- les données d'objet comprennent des données de relief comprenant des données de localisation, et des données d'altitude,
- le moteur 3D calcule les données de faces par triangulation à partir des données d'objet et des données de zoom,
- l'interpréteur Web est agencé pour déterminer un identifiant de données d'objet d'un objet désigné par un utilisateur via l'interface utilisateur à partir de la correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face.,
- le code du moteur 3D est reçu comme données d'affichage à l'initialisation du dispositif et/ou lors de mises à jour,
- le moteur 3D agence les données de blocs de faces dans un objet de type Float32Array, et
- le dispositif comprend des ressources matérielles dédiées à l'affichage.
L'invention concerne également un procédé d'affichage interactif comprenant les opérations suivantes :
a. définir une requête d'affichage comprenant au moins des données de localisation et des données d'affichage,
b. émettre une requête de données de pages Web en correspondance d'une requête d'affichage
c. recevoir des données de page Web correspondantes comprenant des données de cartographie et des données d'objet, et les transmettre à un interpréteur Web comprenant un moteur 3D et un interpréteur WebGL
d. calculer avec le moteur 3D des données de faces d'au moins un objet associé aux données d'objet, et regrouper ces données de faces dans des données de blocs de face, e. transmettre les données de blocs de faces à l'interpréteur WebGL, en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, pour faire calculer des données d'affichage en trois dimensions dudit au moins un objet, f. appeler l'interpréteur Web avec les données de cartographie et les données d'affichage en trois dimensions dudit au moins un objet pour afficher des données de page Web.
D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de 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 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.
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.
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.
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 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 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 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.
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 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.
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.
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, dits de « personnalisation ». En effet, dans les applications connues, il est possible d'activer ou de désactiver 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 non individualisables. A 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 œuvre l'HTML, le JavaScript et le WebGL. Comme on le verra dans ce qui suit, l'interpréteur Web 10 comprend un interpréteur WebGL et un moteur 3D (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 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 du dispositif 2 pour calculer les données à afficher à proprement parler.
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 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 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 correspondent à cette requête.
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 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 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 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, la forme de son toit, et des données de hauteur de bâtiment. Un 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 cela est de considérer qu'un bâtiment est « extrudé » à travers son empreinte au sol sur sa hauteur. 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 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 é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 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 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. 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 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.
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 œuvre 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 données de cartographie et les données d'objet correspondantes. Dans les échanges suivants, le code du moteur 3D n'est plus transmis.
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 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. 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 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 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 triangles.
Simultanément, l'interpréteur Web 10 conserve une correspondance entre les données de face regroupées pour chaque objet du Buffer32 et les identifiants des objets correspondants. 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 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 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).
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é. Cela était impossible avant l'invention ; et
- le maintien de la correspondance entre les objets et les données de face qui leur 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 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 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.
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 « 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 être affichés en dernier, ou ne pas être affichés du tout.
De plus, le fait de transformer la carte, d'une collection de tuiles de fonds de carte 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 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é. Il devient donc 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.
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 conséquence.
La figure 3 représente un exemple de mise en œuvre de l'opération 240. Dans une opération 300, l'interpréteur Web 10 détermine les données de localisation associées au centre de la carte désigné par l'interface utilisateur 8. Ensuite, l'interpréteur Web 10 détermine les paramètres d'affichage comme l'angle de vue et le zoom pour déterminer une nouvelle zone qui doit être représentée par l'affichage.
Dans une opération 320, l'interpréteur Web 10 détermine la liste des tuiles correspondant à la nouvelle vue déterminée à l'opération 300 et ne demande au serveur que celles qu'il n'a pas déjà. En réponse, le serveur 12 retourne la liste des tuiles correspondantes. En variante, le serveur 12 peut conserver une liste des tuiles et objets déjà transmis et/ou considérés comme courants, et transmettre directement les nouvelles données pertinentes.
Enfin, dans une opération 340, l'interpréteur Web 10 procède aux mêmes opérations que pour l'opération 220 pour les données nouvellement obtenues, et met à jour si nécessaire les données déjà connues et affichées.
Par exemple, si un niveau de zoom a été changé, des informations plus fines concernant le relief sont reçues. La mise à jour de l'altitude d'un bâtiment déjà affiché peut être réalisée par simple mise à jour de l'élévation dans la définition des données de faces de bâtiment dans le bloc de données de face. Ainsi, pour les objets déjà affichés, la mise à jour est aussi légère que possible et permet la construction d'une carte en 3D avec données n'arrivant que séquentiellement et dans le désordre.
Toutes les optimisations présentées ci-dessus sont rendues possibles par le fait que l'invention met en œuvre un contexte « objet » décrit plus haut, alors que cela n'était pas possible précédemment.

Claims

Revendications
1. Dispositif interactif, comprenant une interface utilisateur (8) pour définir des requêtes 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 pages Web en correspondance d'une requête d'affichage, une mémoire (4) pour recevoir des données de page Web correspondantes, et un interpréteur Web (10) pour afficher une page Web à partir de données de page Web, lequel interpréteur Web (10) comprend au moins un interpréteur WebGL et un moteur 3D agencé pour calculer, pour des données de page Web données comprenant des données de cartographie et des données d'objet, des données de faces d'au moins un objet associé aux données d'objet, pour regrouper ces données de faces dans des données de blocs de face et transmettre les données de blocs de faces à l'interpréteur WebGL pour le calcul de données d'affichage en trois dimensions dudit au moins un objet en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, l'interpréteur Web (10) étant agencé pour permettre d'afficher des données de page Web à partir des données de cartographie et des données d'affichage en trois dimensions dudit au moins un objet.
2. Dispositif selon la revendication 1, dans lequel la mémoire stocke uniquement des données de type cache.
3. Dispositif selon la revendication 1 ou 2, dans lequel les données d'affichage comprennent des données de zoom, et les données de cartographie définissent un environnement géographique sensiblement centré sur un endroit désigné par les données de localisation, et dont l'étendue dépend des données de zoom.
4. Dispositif selon l'une des revendications précédentes, dans lequel les données d'objet comprennent des données de bâtiment comprenant des données de localisation de bâtiment, des données de forme de toit, et des données de hauteur.
5. Dispositif selon l'une des revendications précédentes, dans lequel les données d'objet comprennent des données de relief comprenant des données de localisation, et des données d'altitude.
6. Dispositif selon la revendication 3 et l'une des revendications 4 et 5, dans lequel le moteur 3D calcule les données de faces par triangulation à partir des données d'objet et des données de zoom.
7. Dispositif selon l'une des revendications précédentes, dans lequel l'interpréteur Web (10) est agencé pour déterminer un identifiant de données d'objet d'un objet désigné par un utilisateur via l'interface utilisateur (8) à partir de la correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face.
8. Dispositif selon l'une des revendications précédentes, dans lequel le code du moteur 3D est reçu comme données d'affichage à l'initialisation du dispositif (2) et/ou lors de mises à jour.
9. Dispositif selon l'une des revendications précédentes, dans lequel le moteur 3D agence les données de blocs de faces dans un objet de type Float32Array.
10. Procédé d'affichage interactif comprenant les opérations suivantes :
a. définir une requête d'affichage comprenant au moins des données de localisation et des données d'affichage,
b. émettre une requête de données de pages Web en correspondance d'une requête d'affichage
c. recevoir des données de page Web correspondantes comprenant des données de cartographie et des données d'objet, et les transmettre à un interpréteur Web comprenant un moteur 3D et un interpréteur WebGL calculer avec le moteur 3D des données de faces d'au moins un objet associé aux données d'objet, et regrouper ces données de faces dans des données de blocs de face,
transmettre les données de blocs de faces à l'interpréteur WebGL, en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, pour faire calculer des données d'affichage en trois dimensions dudit au moins un objet, appeler l'interpréteur Web avec les données de cartographie et les données d'affichage en trois dimensions dudit au moins un objet pour afficher des données de page Web.
EP16742340.9A 2015-06-24 2016-06-22 Dispositif interactif a affichage tridimensionnel Withdrawn EP3314474A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1555807A FR3038090B1 (fr) 2015-06-24 2015-06-24 Dispositif interactif a affichage tridimensionnel
PCT/FR2016/051532 WO2016207551A1 (fr) 2015-06-24 2016-06-22 Dispositif interactif a affichage tridimensionnel

Publications (1)

Publication Number Publication Date
EP3314474A1 true EP3314474A1 (fr) 2018-05-02

Family

ID=54707856

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16742340.9A Withdrawn EP3314474A1 (fr) 2015-06-24 2016-06-22 Dispositif interactif a affichage tridimensionnel

Country Status (4)

Country Link
US (1) US20180322143A1 (fr)
EP (1) EP3314474A1 (fr)
FR (1) FR3038090B1 (fr)
WO (1) WO2016207551A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615241A (zh) * 2022-03-03 2022-06-10 智道网联科技(北京)有限公司 基于高精地图的动态路网显示方法及相关设备

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3038995B1 (fr) 2015-07-15 2018-05-11 F4 Dispositif interactif a affichage personnalisable
FR3042620B1 (fr) 2015-10-16 2017-12-08 F4 Dispositif web interactif a affichage personnalisable
CN108536698B (zh) * 2017-03-02 2022-09-13 腾讯科技（深圳）有限公司 web数据三维展示方法及装置
US10678842B2 (en) * 2017-03-21 2020-06-09 EarthX, Inc. Geostory method and apparatus
CN107832054A (zh) * 2017-11-30 2018-03-23 郑州云海信息技术有限公司 一种房产模型的展示方法和装置
CN108038915A (zh) * 2017-12-13 2018-05-15 中国能源建设集团江苏省电力设计院有限公司 一种基于web端三维模拟的变电站工程进度信息可视化系统
CN109979002A (zh) * 2019-02-28 2019-07-05 华南机械制造有限公司 基于WebGL三维可视化的场景构建系统及方法
CN111599011B (zh) * 2020-07-15 2023-08-04 杭州电力设备制造有限公司 基于WebGL技术的电力系统场景快速构建方法及系统
CN112380309B (zh) * 2020-11-23 2024-10-22 深圳航天智慧城市系统技术研究院有限公司 一种基于WebGL的GIS数据可视化方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2533279C (fr) * 2005-01-18 2011-09-20 Ryan Eccles Systeme et methode pour traiter des donnees cartographiques
US7734412B2 (en) * 2006-11-02 2010-06-08 Yahoo! Inc. Method of client side map rendering with tiled vector data
NL2008690C2 (en) * 2011-04-25 2014-07-15 Google Inc Dynamic highlighting of geographic entities on electronic maps.
GB201204657D0 (en) * 2011-11-18 2012-05-02 Tomtom North America Inc Methods for providing 3D building information
US20130321400A1 (en) * 2012-06-05 2013-12-05 Apple Inc. 3D Map Views for 3D Maps
US20140071119A1 (en) * 2012-09-11 2014-03-13 Apple Inc. Displaying 3D Objects in a 3D Map Presentation

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114615241A (zh) * 2022-03-03 2022-06-10 智道网联科技(北京)有限公司 基于高精地图的动态路网显示方法及相关设备

Also Published As

Publication number Publication date
US20180322143A1 (en) 2018-11-08
WO2016207551A1 (fr) 2016-12-29
FR3038090B1 (fr) 2017-08-04
FR3038090A1 (fr) 2016-12-30

Similar Documents

Publication Publication Date Title
EP3314474A1 (fr) Dispositif interactif a affichage tridimensionnel
US10274324B2 (en) Dynamic highlighting of geographic entities on electronic maps
US8902282B1 (en) Generating video from panoramic images using transition trees
TWI459283B (zh) 可調整且革新的行動裝置街道視界
US8026929B2 (en) Seamlessly overlaying 2D images in 3D model
US9754413B1 (en) Method and system for navigating in panoramic images using voxel maps
US20230376511A1 (en) Temporal Layers for Presenting Personalization Markers on Imagery
EP2731084A1 (fr) Procédé d'augmentation de la réalité
JP2010537348A (ja) 解像度の連続した付加レイヤー内の地理空間テクスチャ・データを選択的に読み出し表示するための地理空間データシステム、および関連した方法
US20150199383A1 (en) Systems and Methods for Indexing and Retrieving Images
CN101802875B (zh) 用于基于用户选择的视点选择性地检索并显示地理空间纹理数据的地理空间数据系统及相关方法
EP3323044A1 (fr) Dispositif interactif a affichage personnalisable
US20160191773A1 (en) Distribution of location-based augmented reality captures
WO2018149321A1 (fr) Procédé et dispositif de fourniture d'informations à un objet interactif
EP3362912A1 (fr) Dispositif web interactif a affichage personnalisable
WO2014170482A1 (fr) Procede de generation d'un flux video de sortie a partir d'un flux video large champ
JP2014182838A (ja) 地理的エリアの公開格付けを取得する情報システム
US20250076063A1 (en) Navigation-integrated scenic location value and route planning
JP2022007881A (ja) 情報提供サービスプログラム及び情報提供サービス用情報端末装置
US9534915B2 (en) Dynamic attraction inference in route recommendations
WO2012104290A1 (fr) Procédé et dispositif de traitement de séquences d'images d'une scène et système de surveillance d'une scène comportant un tel dispositif
EP1864260B1 (fr) Procede de reconstruction d'image dans un graphique vectoriel
WO2011144435A1 (fr) Système de traitement de données relatives à des bâtiments
FR2974216A1 (fr) Procede de restitution d'une sequence d'images simulant un survol d'un trou d'un parcours de golf
WO2025210125A1 (fr) Procédé de gestion de contenus à afficher dans un environnement 3d

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171215

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190227

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190910