• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A method of visualizing a digital plane (PLAN) by computer devices (M1, M2, ... Mn) connected through a network (RI) to a server (M0), each device (M1, M2 , ... Mn) storing at least one visualization file, comprising a matrix image, identification data, and version data, a screen (DISPLAY) and a processing unit for displaying on the screen the image visualization file, the method comprising: by the server (M0): - receiving a source file of the plan; the production, according to the source file, of at least one intermediate file, comprising a matrix image of at least a part of the plan, identification data and version data associated with the plan; sending each intermediate file to the devices; by each device (M1, M2, ..., Mn): the recording of each intermediate file; and displaying on the screen (DISPLAY) of the plane according to the raster image or images of the intermediate file (s) having the identification data associated with the plane and the most recent version data.
    公开号:FR3043806A1
    申请号:FR1561026
    申请日:2015-11-17
    公开日:2017-05-19
    发明作者:Loic Cueroni；Michel Kuehn
    申请人:Loic Cueroni；
    IPC主号:
    专利说明:

    Ces sous-images SI(i,j) sont de hauteur en pixels égale à Hd et de largeur en pixels égale kLd.
    Toujours dans ce même repère R, pour i entier variant de 0 à p-1, la sous-image SI(i,q) est composée de l’ensemble des pixels du master de coordonnées (x ;y) tels que :
    Ces sous-images S(i,q) sont de hauteur en pixels égale à 5 et de largeur en pixels égale à Ld.
    Toujours dans ce même repère R, pour j entier variant de 0 à q-, la sous image SI(p,j) est composée de l’ensemble des pixels du master de coordonnées (x ;y) tels que :
    Ces sous images S(p,j) sont de hauteur en pixels égale à Hd et de largeur en pixels égale à r.
    Toujours dans ce même repère R, la sous image SI(p,q) est composée de l’ensemble des pixels du master de coordonnées (x ;y) tels que :
    Cette sous-image S(p,q) est de hauteur en pixels égale à 5 et de largeur en pixels égale à r.
    La décomposition du master en ces sous-images est assurée, dans le cadre de cette réalisation préférée, au moyen de la fonction « drawImage » de la boite à outil PDF BOX. A l’issue de ces étapes effectuées par le serveur MO, le plan au format PDF, identifié par un couple (DATE, NOM PLAN) unique, est ainsi décomposé en P masters, eux-mêmes décomposés en (p+1) fois (q+l) sous-images matricielles dont la résolution est connue (100dpi) au format PNG, et dont les dimensions, qui sont aussi connues, sont inférieures aux dimensions techniques minimales Ld, Hd, des écrans des dispositifs Ml,..., Mn. Le serveur MO découpe donc le plan initial au format PDF en Q images matricielles mémorisées dans un format image DOCPNGl,..., DOCPNGQ, par exemple PNG, chacune identifiées de manière unique par sept paramètres (DATE, NOM PLAN, PAGE, i, j, LARGEUR, HAUTEUR) mémorisés en tant que métadonnées du fichier PNG correspondant, les paramètres LARGEUR et HAUTEUR étant respectivement la largeur et la hauteur en pixels de l’image. Ces sept paramètres, et notamment les paramètres PAGE, i et j, codent de manière unique la position de l’image matricielle dans le plan et sont utilisés par les dispositifs Ml, ..., Mn pour la recomposition du plan. Les dispositifs Ml, ..., Mn mémorisent les dimensions Ld et Hd pour cette recomposition ou, dans une autre variante, ces dimensions sont mémorisées également en tant que métadonnées des sous-images SI et donc communiqués aux dispositifs Ml, ..., Mn.
    Toutes les images au format PNG DOC PNGl,..., DOC PNGQ, identifiées par leurs paramètres, sont ensuite communiquées, en 34, par le serveur MO à chacun des dispositifs Ml, ..., Mn. De par leur format, ceux-ci sont d’ores et déjà assurés de pouvoir les visualiser, une image matricielle étant en effet usuellement lisible par tout dispositif informatique classique.
    Suite à la réception, en 36, de la série d’images DOC PNGl,..., DOC PNGQ par un dispositif informatique Ml, ..., Mn, ce dernier enregistre les images reçues dans sa mémoire de masse et puis met en œuvre une recomposition du plan numérique découpé.
    Plus particulièrement, chaque dispositif Ml, . . ., Mn embarque un logiciel qui permet de reconstituer chaque master issu du fichier source DOC PDF en juxtaposant les images ayant le triplet (DATE, NOM PLAN, PAGE) identique. On notera sur ce point que l’algorithme de recomposition décrit ci-après n’applique aucune transformation, ou traitement d’image, aux images de la série, et ne consiste qu’en des comparaisons d’entiers et à la définition de conteneurs. H peut ainsi être mis en œuvre y compris par des dispositifs informatiques aux ressources matérielles et logicielles très limitées.
    Plus particulièrement, dans une étape 38, le dispositif informatique Ml, ..., Mn génère automatiquement P objets interprétables, fidèles aux P masters d’origines, résultant d’une organisation intelligente des sous-images issues du master au moyen d’un fichier de visualisation tel que décrit à la figure 2, et plus particulièrement un document HTML qui permet d’afficher les images et naviguer entre elles, ainsi qu’entre les différentes pages, afin de visualiser le plan. Les P objets en question sont par exemple des conteneurs HTML d’un fichier HTML, chaque objet étant composé de 3 étages, à savoir composé : d’un conteneur principal, dans lequel se retrouvent des conteneurs de ligne ; lesdits conteneurs de ligne comprenant des conteneurs d’image ; lesdits conteneurs d’image appelant les sous-images au format PNG enregistré dans la mémoire du dispositif.
    Ces P objets peuvent être affichés par le dispositif informatique destinataire. Comme décrit ci-dessus, dans le cas particulier d’un affichage au moyen d’un navigateur internet, ces conteneurs sont par exemple des balises « div » et des balises « img ».
    Notamment, pour chaque ensemble d’images reçues ayant les mêmes valeurs de paramètres (DATE, NOMPLAN), mais ayant une valeur de paramètre (PAGE) différente, un objet interprétable est crée dans un document HTML DOC HTML identifié par les paramètres (DATE, NOM PLAN, PAGE) et enregistré par le dispositif informatique. Pour générer le conteneur principal de cet objet, toutes les images ayant les paramètres (DATE, NOM PLAN, PAGE) égaux sont sélectionnées. Pour chaque valeur de paramètre « i » parmi les images sélectionnées, la somme des paramètres « HAUTEUR » des images ayant cette valeur « i » est réalisée, cette somme étant notée H* et qui en toute logique est égale à la hauteur Hm du master correspondant. Cette opération est également réalisée pour calculer une largeur L* qui en toute logique est égale à la largeur en pixels Lm du master correspondant. Une fois la hauteur H*et la largeur L * du master reconstituées, un conteneur rectangulaire, dont la hauteur, en pixels, vaut H* et dont la largeur, en pixels, vaut L* est généré dans le document HTML. Il s’agit du conteneur principal CP de l’objet. On note R* le repère orthonormé prenant pour origine le coin inférieur gauche de ce conteneur et dont la norme est égale à 1 pixel.
    Ainsi, on a dans R* le conteneur principal qui contiendra l’ensemble des pixels de coordonnées (x ;y) tels que :
    A l’intérieur de ce conteneur principal CP, des conteneurs de lignes sont ensuite inscrits. Pour cela, et toujours en travaillant à partir du groupe d’images reçues ayant les mêmes valeurs (DATE, NOM PLAN, PAGE), le dispositif informatique identifie la valeur q* qui est l’entier positif le plus élevé parmi les valeurs « y». En toute logique q*=q. On remarque que le découpage initial a été fait de manière à ce que les images ayant les mêmes valeurs j aient aussi la même valeur « hauteur ». Cette valeur vaut h*= Hd pour j entier variant de 0 à q*-1 et .v*=.v pour j=q*. Pour j entier croissant de 0 à q*, le dispositif informatique génère un conteneur de lignes C(j) rectangulaire dont la largeur en pixels vaut Z* et dont la hauteur est égale à la valeur « hauteur » des images ayant la même valeur de paramètre j. Ce conteneur C(j) est contenu dans le conteneur principal de tel sorte que son coin inférieur gauche coïncide avec celui du pixel de coordonnées (1 ; j./z*+l) dans R*.
    Ainsi, on a dans R* : - Pour q*> 0, et pour j entier variant de 0 à q*-l, le conteneur de lignes C(j) contiendra l’ensemble des pixels de coordonnées (x ;y) tels que :
    - Pour j = q*, le conteneur de lignes C(q*) contiendra l’ensemble des pixels de coordonnées (x ;y) tels que :
    A l’intérieur de chacun des conteneurs de lignes C(j), le dispositif informatique incorpore ensuite des conteneurs d’image, nommés CI(i,j). Pour cela, et toujours en travaillant à partir du groupe de images reçues ayant les mêmes valeurs (DATE, NOM PLAN, PAGE), le dispositif informatique identifie la valeur p* qui est l’entier positif le plus élevé parmi les valeurs « z ». En toute logique p*=p. On remarque que le découpage initial a été fait de manière à ce que les images ayant les mêmes valeurs de paramètre « / » aient aussi la même valeur « LARGEUR ». Cette valeur vaut l*=Ld pour i entier variant de 0 à p*-1 et r*=r pour i=p*. Pour i entier croissant de 0 à p*, à j fixé, le dispositif génère donc le conteneur d’image CI(i,j) rectangulaire dont la hauteur en pixels est égale à la hauteur du conteneur de ligne C(j), c’est à dire soit h*, soit 5*, et dont la largeur est égale à la valeur du paramètre « LARGEUR » des images de même i. Ce conteneur CI(isj) est contenu dans le conteneur de lignes C(j) de tel sorte que son coin inférieur gauche coïncide avec celui du pixel de coordonnées (/'./*+1 J.h*+1) dans R*.
    Ainsi on a dans R* : - Pour c/*>0 et p*>0, pour j entier variant de 0 à q*-1, pour i entier variant de 0 à p*-1, le conteneur d’image CI(i,j) comprend l’ensemble des pixels du master initial de coordonnées (x ;y) tels que :
    - Pour i = p*, le conteneur d’image CI(p*,j) comprend l’ensemble des pixels du master initial de coordonnées (x ;y) tels que :
    - Pour j=q*, pour i entier variant de 0 àp*-l, le conteneur d’image CI(i,q*) contient l’ensemble des pixels du master initial de coordonnées (x ;y) tels que :
    - Pour i =p*, le conteneur d’image CI(p*,q*) contient l’ensemble des pixels du master initial de coordonnées (x ;y) tels que :
    A l’intérieur de chacun des conteneurs d’image CI(i,j), et toujours en travaillant à partir du groupe de sous-images reçues ayant les mêmes valeurs (DATE, NOM_PLAN, PAGE), on intègre, par un appel au moyen d’un tag HTLM, par exemple IMG, l’image SI(i,j) mémorisée dans la mémoire de masse du dispositif informatique, en conservant dans R* l’orientation qu’elle avait dans R et en superposant le pixel constituant son coin inférieur gauche dans R au pixel constituant le coin inférieur gauche de CI(i,j) dans R*.
    Une variante de mise en œuvre de ce protocole de recomposition consiste à générer, au niveau du conteneur de rang 2, des conteneurs de colonne en lieu et place de conteneurs de ligne en travaillant sur « i » avant de travailler sur « j ». Cette variante conduit au final à des Cl(ij) superposables dans R* aux CI(i,j) générés dans la cas de base.
    En définitive, l’objet ainsi constitué au niveau du dispositif informatique est une représentation fidèle du master décomposé par le serveur MO ayant les mêmes valeurs (DATE, NOMPLAN, PAGE). Sa hauteur H* est égale à Hm, la hauteur du master de référence ; sa largeur L* est égale à Lm, la largeur du master de référence. Cet objet est également de même résolution que le master (dans le cas présent : 100dpi).
    Chaque master induit par exemple la production d’une page HTLM particulière, et les pages HTML sont liées les unes aux autres pour produire un ensemble de pages successives ou bien produit une seule page HTML enregistrant les P objets et permettant la navigation entre ceux-ci. Le fichier source de départ, au format PDF et comportant plusieurs pages, est ainsi transformé en un ensemble de pages correspondantes, chacune constituée de la juxtaposition, lors de l’aifichage sur le navigateur internet en 40, de sous-images matricielles correspondant au découpage de la page du document PDF initiale. Par ailleurs, comme cela est connu, l’utilisateur peut cliquer sur chacune des portions de cette page reconstituée (i.e. chaque sous-image du master correspondant) et visualiser directement l’image qui est affichable en plein format en raison des dimensions choisies pour celles-ci en fonction du plus petit dénominateur commun parmi les écrans des dispositifs informatiques Ml, ..., Mn.
    En outre, chaque conteneur principal CP est identifié par un unique triplet (DATE, NOM PLAN, PAGE) qui le caractérise. On appelle série de conteneurs, l’ensemble des conteneurs principaux ayant les mêmes valeurs de paramètre « NOM PLAN », le nom de cette série de conteneurs étant cette valeur « NOM PLAN ».
    Les valeurs des paramètres « DATE » et « NOM PLAN » permettent ainsi de différencier, sur chacun des dispositifs informatiques ΜΙ,.,.Μη, les conteneurs générés à partir des éléments d’un plan nouveau, de ceux générés à partir d’un plan relevant de la mise à jour d’une série de plans. Pour cela, et dans le cadre de cette réalisation préférée, il a été choisi de comparer la valeur « NOM PLAN » du conteneur principal ainsi généré à tous les noms des séries de conteneurs mémorisés dans le dispositif informatique Ml,..., Mn.
    Si la valeur du paramètre « NOMPLAN » du conteneur généré est différente de tous les noms des séries de conteneurs connus de la machine, le conteneur est identifié comme étant l’une des pages d’un plan nouveau. Il devient le premier d’une série portant son nom.
    Si la valeur du paramètre « NOM PLAN » du conteneur généré est identique à celui d’une série de conteneurs déjà connue de la machine, le conteneur est identifié comme étant la version la plus à jour de l’une des pages du plan correspondant à cette série. On compare alors la valeur « PAGE » de ce conteneur à toutes les valeurs pages de cette série de conteneurs. Soit cette valeur « PAGE » est différente de toutes les valeurs « PAGE» des conteneurs de la série (supérieure, en toute logique) : dans ce cas, le conteneur généré est identifié comme étant une nouvelle page du plan. Soit cette valeur « PAGE » est égale à une valeur « PAGE » que possèdent un ou plusieurs conteneurs de la série : dans ce cas, le conteneur généré est identifié comme étant la version la plus à jour de tous les conteneurs de même valeur « PAGE » dans la série. On peut d’ailleurs vérifier, dans ce dernier cas, que la valeur « DATE » du conteneur généré est supérieure à toutes les valeurs « DATE » des conteneurs de même valeur « DATE » dans la série.
    Selon une réalisation variante de ce moyen d’identification de la version la plus à jour du conteneur constituant l’une des pages d’un plan, il est possible de demander à l’opérateur, au moment du chargement du fichier source, d’attribuer un numéro de version au document soumis à l’enregistrement. Ce numéro de version peut être imposé comme étant supérieur à tous les numéros de version des plans déjà connus dans la même série. Indépendamment de sa date de chargement, le conteneur ayant le numéro de version le plus élevé parmi ceux connus de la machine destinataire ayant les mêmes couples (NOM PLAN, PAGE), sont identifiés, dans ce cas de figure, comme étant les pages les plus à jour.
    Selon une autre réalisation variante, la détermination du conteneur constituant la page la plus à jour peut se faire uniquement par comparaison des valeurs « DATE » des conteneurs ayant les mêmes couples (NOM_PLAN, PAGE).
    Enfin, une troisième réalisation variante qui combinerait à la fois la comparaison de la « DATE » et la comparaison du numéro de version aurait l’avantage d’être encore plus fiable si le système de communication utilisé entre les dispositifs MO, Ml, ..., Mn ne permet pas une liaison synchrone permanente et si différents opérateurs peuvent procéder à des enregistrements quasi-simultanés depuis deux dispositifs distincts, de type serveur MO. Ce troisième moyen de mise en évidence de la version la plus à jour de la page recherchée permet d’aboutir à un résultat fiable même si l’une des deux serveurs MO est provisoirement déconnectée du système, ou si l’un des deux serveurs MO a besoin d’un délai de traitement significativement plus long que la première. On peut ainsi comparer les numéros de version, pour éliminer les doublons ou les erreurs (cas de deux opérateurs procédant à un chargement, en même temps)
    En définitive, la machine destinataire Ml, ..., Mn est ainsi bien capable d’identifier les versions les plus à jour des différentes pages de plans qui lui sont transmises. Ces pages de plans lui sont communiquées dans un format choisi de manière à ce qu’elles puissent les lire et interagir avec elles (ici, un format constitué de conteneurs principaux, contenant des conteneurs de lignes, contenant des conteneurs d’images, contenant des images).
    Il est ainsi possible d’effectuer des mesures à partir de cet objet disponible sur les dispositifs Ml,..., Mn, notamment comme si ces mesures étaient faites sur le serveur MO lui-même. Ces mesures, qui sont effectuées avec une incertitude de l’ordre du pixel (discrétisation de l’image) fournissent une très bonne approximation de la dimension physique, qui aurait été relevée sur l’impression papier du fichier source. A l’échelle d’impression papier 1 pour 1, la loi d’approximation suivante est ainsi vérifiée :
    Cette loi, qui permet d’approximer des longueurs droites, permet également d’approximer, par extrapolations mathématiques, des longueurs curvilignes, des surfaces. L’ensemble des mesures et annotations sont par exemple mémorisées dans un document texte faisant partie du fichier de visualisation ou dans une base de données appelée par le dit fichier. Ainsi, en cas de mise à jour d’un plan, par exemple la mise à jour d’une page, ce document est toujours présent dans le fichier de visualisation, et donc applicable à la page mise à jour.
    Il a été décrit une visualisation du plan sur les dispositifs Ml, Mn basée sur la production d’un document HTML, mémorisé dans la mémoire de masse de chaque dispositif. Ceci permet notamment de recomposer le plan sur les dispositifs. L’invention ne se limite cependant pas à ce type de recomposition et d’affichage. Notamment, les tablettes et smartphones permettent un affichage dynamique des images.
    Dans le cadre d’une autre réalisation préférée, les conteneurs sont organisés en Panels, à savoir : - un panel principal, dans lequel se trouvent des Panels de lignes ; lesdits Panels de lignes comprenant des Panels d’image ; et - lesdits Panels d’images appelant les sous-images au format PNG enregistrées dans la mémoire du dispositif.
    Ce mode de réalisation est utilisé pour l’affichage sur des terminaux de type tablettes ou smartphones équipées par exemple d’un système d’exploitation Windows. Dans ce cas de figure, les commandes d’affichage des sous-images au format PNG ne sont pas stockées dans un fichier matérialisé en tant que tel, mais sont simplement enregistrées avec une adresse connue, dans la mémoire RAM du dispositif. L’ensemble des sous-images attribuées à un P objet constitue ce que Ton peut appeler un fichier « virtuel ». Ici, la construction de l’interface graphique est gérée par le système d’exploitation qui s’appuie sur un objet C# créé dynamiquement à partir du Panel constituant le conteneur principal. Notamment, un tel objet est crée à la volée en fonction uniquement des images effectivement visualisée sur l’écran, et est modifié dès que l’utilisateur commande la visualisation d’au moins une autre image.
    Selon une variante de réalisation, les images correspondant aux versions les plus anciennes de plans sont supprimées de la mémoire des dispositifs informatiques Ml, ..., Mn, ces derniers conservant donc uniquement la version la plus à jour.
    Selon une variante de réalisation, lorsque le fichier source reçu mène à un découpage identique à celui déjà effectuée pour la dernière version du plan, les conteneurs sont donc déjà appropriés, de sorte que la mise à jour consiste uniquement en le changement de lien d’appel d’image des conteneurs d’image. En variante, un simple écrasement des images existantes permet de mettre à jour le plan en ne conservant que la version à jour.
    Selon une variante de réalisation, lorsque le fichier source reçu mène à un découpage identique à celui déjà effectuée pour la dernière version du plan, les conteneurs sont donc déjà appropriés, de sorte que la mise à jour consiste uniquement à changer les sous-images ayant fait l’objet d’une modification, d’une version à l’autre. La comparaison des sous-images entre elles peut être effectuée au niveau de la machine initiale MO de telle sorte que seules les sous-images présentant une modification sont ensuite diffusées à l’ensemble du système. Cette réalisation permet de réduire le volume de données à transférer, de réduire les temps de calcul sur les terminaux ΜΙ,.,.,Μη, et de préserver la capacité mémoire des machines.
    Selon une réalisation variante de ce procédé de traitement, tout le travail effectué au niveau d’un serveur dédié MO peut être réalisé sur un des dispositifs informatiques ΜΙ,.,.,Μη sur laquelle le fichier source serait chargé par l’utilisateur, si ce dispositif possède les outils, les algorithmes et la puissance de calcul nécessaires. La préparation est alors réalisée une fois sur cette machine, et pour le compte de l’ensemble des dispositifs ΜΙ,.,.,Μη, puis diffusée à toutes les autres dispositif. Dans le cadre de cette variante de réalisation, les algorithmes restent inchangés, mais la machine de départ peut être un ordinateur portable suffisamment puissant pour pouvoir effectuer le traitement.
    Selon une autre variante de réalisation de ce procédé de traitement, une partie du travail effectué au niveau du serveur MO est réalisé sur un des dispositifs informatiques ΜΙ,.,.,Μη sur lequel le fichier source est chargé par l’utilisateur, à condition que ce dispositif possède les outils, les algorithmes et la puissance de calcul nécessaires à ces premières étapes de travail. Ces éléments, partiellement traités, sont ensuite diffusés au serveur MO qui finalise le traitement et renvoie l’ensemble des fichiers images à tous les dispositifs ΜΙ,.,.,Μη. Dans le cadre de cette variante de réalisation, le dispositif de départ peut être un ordinateur portable qui ne possède pas toute la puissance de calcul nécessaire, ou qui ne bénéficie pas de tous les logiciels ou algorithmes nécessaires au traitement complet du fichier source. Selon cette variante de réalisation, chaque étape décrite ci-avant mise en œuvre par le serveur MO, prise individuellement, est réalisée sur l’une ou l’autre des dispositifs MO, Ml, ..., Mn, une fois, et pour le compte de l’ensemble des dispositifs MO, Ml,.. ,,Mn du système.
    Selon une variante de réalisation du procédé, le fichier source chargé par l’utilisateur peut être au format DWG (Autocad). Dans ce cas de figure, le serveur MO possède une boite à outils permettant de transformer ce document source en une ou plusieurs images planes pixelisées PNG. Cette boite à outil peut par exemple être RealDWG. Dans le cas présent, les pages du plan peuvent être les différents onglets du document DWG.
    Selon une variante de réalisation du procédé, le fichier source chargé par l’utilisateur peut être une maquette en trois dimensions représentant un objet construit ou à construire. Dans le cadre de cette réalisation variante, le serveur MO dispose d’une boite à outils permettant d’extraire des images planes et pixelisées de cette maquette, éventuellement au moyen d’une interface graphique spécifique, disponible sur le serveur MO et permettant de positionner des coupes choisies.
    METHOD FOR VISUALIZATION OF A PLAN BY COMPUTING DEVICES
    FIELD OF THE INVENTION The invention relates to the field of computer management of digital plans, and more generally to technical drawings. The invention is particularly applicable to the visualization of plans by a fleet of computing devices, eg laptops, tablets, smartphones, made available to users moving on site, including mobile and / or different computing devices.
    State of the art
    A plan, or more generally a technical drawing, is by nature a particular document: it is about the graphic or schematic modeling, of an object or a system (eg buildings, cities, machines, etc), existing or to create, which is characterized by a number of information that are, for example, its update number (usually called "version"), its name, scale, ratings and orientation. Contextual information, depending on the purpose of use of the plan, is also associated with the plan, such as notations, distance measurements on the plan, etc. All of this information, the plan itself which corresponds to a digital image, that is to say the digital version of a paper plan, and the information associated with it, can take several formats ( eg pdf - "portable document format", DWG - associated with autoCAD © software, etc.) according to the wishes of the user and / or the software at his disposal to produce a computer file encoding the plan and its associated information.
    It is known to use drawings or technical drawings within collaborative mobile computing devices made available to employees of a company, such as so-called "lifting of reserves" computer devices used in the construction industry. to generate lists of tasks to perform and to facilitate the monitoring of the activity. These devices generally consist of n machines [Ml, ..., Mn] (tablets, laptops, mobile phones, servers), communicating with each other by means of a telecommunication network, which can be for example of the EDGE type. , 3G, 4G or Wifi, and each hosting a software allowing users to generate information interacting with the pages of the most up-to-date plan known to the system. The plans constitute for these devices input data essential for their proper operation. The support of these plans does not consist in simply saving the data they contain, but generally requires the implementation of a more or less complex procedure depending on the case, aiming to prepare the plans so as to make them exploitable. by the devices.
    The problem of recording plans in such devices is that we do not know a priori the technical characteristics of these devices (eg their hardware and software resources), which are likely to be different, and even rather limited in the case mobile terminals, in particular of the type of tactile tablets or smartphones. It is also not known a priori what will be the complexity and the size of the plans submitted to the devices. These uncertainties make it difficult, if not impossible, to implement effective automated processing of plans, including registration. Thus, it is not possible to say, a priori, whether a device receiving a plan is able to properly process the computer format used and / or the pixel size of this plane (is the computing power sufficient it has the right algorithms ). A palliative solution is to involve a human operator at one of the devices. This operator reads the plan and manually performs the preparatory work to create a set of computer files and data interpretable by the computing devices. This expensive solution, therefore, requires to involve a human operator in each new plan, and each new version of a plan. In particular, when a plan is updated, a lot of work has to be done by the operator to ensure that the information associated with the old version of the plan (measurements, annotations, etc.) is reusable for the new version of the plan. plan. Often, this operation is so expensive that this information is simply not reused. In a way, therefore, there is no "version" of the plan itself, a new version of plan being treated rather like a new plan.
    Expose the invention
    The purpose of the present invention is to propose a method of processing a digital plane that allows the plan to be supported by the devices by means of limited hardware and software resources, while allowing the plans to be updated without loss of power. information. To this end, the subject of the invention is a method of viewing a digital plane by computer devices, connected through a computer network to a computing device forming a server, each computing device comprising a computer memory for memorizing at least a computer file, called "visualization", comprising at least one matrix image, identification data, and version data, a screen and a processing unit for controlling the screen so as to display the matrix image of the visualization file stored in said memory, the method comprising: by the computing device forming a server: the reception of a computer file, called "source", encoding the digital plane; the production, according to the source file, of at least one computer file, called "intermediate", comprising a matrix image of at least part of the digital plane, digitally associated identification and version data, and resolution data of the matrix image; - the sending of each intermediate file to the computing devices; by each computing device: receiving and recording each intermediate file sent by the server device; and displaying the digital plane on the screen according to the one or more raster images of the intermediate file (s) having the associated identification data associated with the digital plane and the latest version data.
    As is known, a computer file is a collection of digital information gathered under the same name, stored on a computer storage medium and manipulated as a unit. Similarly, a matrix image, or "point map" (of the English "bitmap"), is an image consisting of a matrix of points, usually colored or in gray level, that is to say, consisting of a table, grid, etc., where each box has its own color or gray level value and is considered a point in the image. It is therefore a juxtaposition of points of color or gray level forming, as a whole, an image.
    In other words, the invention provides an additional device centrally managing the plans. Unlike the usual computing devices, this central server device is designed to have sufficient hardware and software resources to manage different computer formats for the plans, and automatically converts the source computer file of a plan into one or more raster images. while producing in parallel the data associated with this plan. As is known a matrix image (for example stored in an "image" format, eg PNG, JPEG, etc.) is a computer object that can handle most of the known computing devices, and this through a significant number software or applications (eg an internet browser), at least one of which is systematically installed in any computing device. Not only, the raster image is a simple computer object to manage, but it also allows simple annotations and measurements, and thus offers a simple interactivity with the user of a computing device. Then, the viewing format consists of a clear separation between the visualized content, ie the one or more raster images constituting the digital plane, and the data associated with the plane. Thus, for updating the plan, it is sufficient to update the raster images of the associated visualization file. As, moreover, the plane is coded in the form of raster images, the information associated with the plane, such as the measurements or annotations, remain valid, and are thus easily reused, either directly or after a very simple transformation, on the new version of the plan.
    According to one embodiment of the invention, each intermediate file comprises resolution data of the matrix image or the computer device stores the resolution of the matrix image. .
    More particularly, the computing device implements: if a visualization file, having identification data identical to that of the intermediate file received, is stored in the memory of said device, the updating of at least one matrix image of said visualization file according to the matrix image of the intermediate file, keeping the identification data of the visualization file; if no display file, having identification data identical to that of the intermediate computer file, is stored in the memory of said device, the production of a display file comprising the identification, version, and resolution, and the matrix image of the intermediate file, and storing the file produced in the memory of said device.
    In particular, the production of the intermediate file comprises the production of resolution data of the matrix image, and in which the resolution data of the visualization file are updated according to the resolution data of the intermediate file.
    According to one embodiment, the source file is a file in a vectorized computer format, in particular a pdf file or autocad.
    According to one embodiment, the computer device: produces and stores an HTML file containing container type tags according to the dimensions of the matrix image and image-type tags linking the stored image to the HTML file; - is configured to display the image by means of an internet browser.
    According to one embodiment, the computing device produces a dynamic computer object, stored in a random access memory of the device, comprising image containers incorporating only the matrix image or images displayed on the screen.
    According to one embodiment, the screens of the computing devices each comprise a matrix of at least L x H display pixels: and the server device: stores the LetH parameters; splits the digital plane into a series of raster images of dimensions less than or equal to L x H pixels if the digital plane has Lp x Hp pixels with Lp> L and / or Hp> H, and produces an intermediate file for each raster image of said series; and the computing device updates or creates the view file according to the series of images contained in the intermediate files.
    In particular, the matrix of L x H pixels corresponds to the screen of smaller size among the screens of the computing devices. The invention also relates to a computer system for viewing a digital plane, comprising computer devices, connected through a computer network to a computing device forming a server, each computing device comprising a computer memory for storing at least one computer file, called "visualization", comprising at least one raster image, identification data, and version data, a screen and a processing unit for controlling the screen so as to display the raster image of the file viewing device stored in said memory, the server computing device being configured for: receiving a so-called "source" computer file encoding the digital plane; the production, according to the source file, of at least one computer file, called "intermediate", comprising a matrix image of at least part of the digital plane, digitally associated identification and version data, and resolution data of the matrix image; sending each intermediate file to the computing devices; and each computing device being configured for: receiving and recording each intermediate file sent by the server device; and displaying the digital plane on the screen according to the raster image or images of the intermediate file (s) having the identification data associated with the digital plane and the most recent version data.
    This system is able to implement a method of the aforementioned type.
    BRIEF DESCRIPTION OF THE FIGURES The invention will be better understood on reading the following description, given solely by way of example, and with reference to the appended drawings, in which like references designate identical or similar elements, and in which: Figure 1 is a schematic view of a computer system according to the invention for processing and viewing a digital plane; FIG. 2 is a schematic view of the constituent data of a visualization file according to the invention; and FIG. 3 is a flowchart of a method for processing and displaying a plan according to the invention.
    Detailed description of the invention
    Referring to FIG. 1, a system 10 according to the invention comprises a plurality of computer devices M1, M2,..., Mn each equipped with a processor, a random access memory, a storage memory of mass, a display screen and a communication module with at least one IT communication network RI, for example a wireless communication network type WIFI, EDGE, 3G, 4G, etc., and each board an operating system for managing the various hardware and embedded software components. Each device also embeds software capable of supporting files or objects called "visualization", as described below. For example, the devices Ml, M2, ..., Mn are touch tablets, laptops and / or smartphones, constituting a fleet of portable devices for the use of collaborators in the field of construction, maintenance, works, real estate management, maintenance of roads or networks, or more generally any job requiring on-site intervention of mobile technical teams possibly belonging to different structures or companies. The devices M1, M2,..., Mn may be identical, or different as is usually the case. In particular, the arrangements are different in the case where different companies are working together and exchanging information on the same project. These companies do not necessarily have the same computer equipment available (heterogeneity of machines Ml, .. ,, Mn).
    The system 10 also comprises a central device MO, for example UNIX server, able to communicate with each device Ml, M2, ..., Mn through the network RI, via for example a WEB type application developed in JAVA. The server MO has appropriate hardware and software resources for processing different types of computer formats under which a plan can be stored, such as for example vectorized files of the PDF type (for "portable document format") or DWG (computer format of the software autoCAD ®).
    FIG. 2 illustrates an exemplary plan view computer file stored in the memory of each device M1, M2,..., Mn. The viewer file consisting of: a first HTML DOC file having META metadata, including ID data uniquely identifying the plan and DATE version data uniquely identifying the version of the plan, and a HTML portion comprising a set of containers, for example defined by DIV tags, connected to images, for example by means of IMG tags; second computer files of the DOC PNG1 image type, ... DOC_PNGP, for example in the PNG format (for "portable network graphie"), constituting a breakdown of the digital plane. Each image file comprises conventional META1 metadata (eg the IHDR header of a PNG format including the height and width of the image), a block of pixel data constituting an image, as well as META2 metadata specific to the invention. , including image resolution data (RES) and image position data (POS) in the plane, as well as the identification (ID) and version (DATE) data of the plane; a third file DOC_TXT comprising all the measurements and annotations made on the plane by means of the device, and recorded for example in a text format.
    As will be described below, the reading of the HTML DOC file in a web browser makes it possible to redial the digital plane by displaying the raster images stored in the DOC_PNGl, ... DOC_PNGQ files, as well as the measurements and annotations contained in the file. DOCTXT.
    An embodiment of a method for processing and displaying a digital plane according to the invention will now be described, illustrated by way of example in relation to a source file of PDF type comprising P pages, P being an integer greater than or equal to 1. The PDF format is usually used for communicating plans between computing devices. However, because of its vectorial nature, the display of a PDF file requires significant hardware resources, the operations of enlarging and reducing a vector image being for example very long on devices such as a touchscreen tablet not a powerful processor and a large RAM.
    The method according to the invention comprises two main sets of computer processing, a first set of processing being implemented by the server MO, capable of interpreting PDF files, eg through a toolbox such as PDF BOX available under license Apache 2.O., and a second set of treatments being implemented by each device Ml, M2, ..., Mn. The first set of treatments is advantageously optimized according to the display capabilities of the devices Ml, M2 ,. . ., Mn. More particularly, a large pixel digital plane is cut into matrix images of the same dimensions, or smaller, than the dimensions Ld (width) and Hd (height) in pixels of the smallest screen among the screens of the devices Ml, M2 , ..., Mn. Thus, each device is capable of displaying in full format each matrix image produced by the server MO. The second set of treatments consists in recombining the matrix images in a visualization file so as to display the digital plane on the screens of the devices Ml, M2,..., Mn.
    Referring to the flowchart of FIG. 3, the method begins, at 20, with the receipt by the system 10 of a DOC PDF file encoding a digital plane, this file being able to be received by one of the devices Ml, M2, ..., Mn or by the server MO. In 22, the receiving device determines whether the submitted plan is a new plan or whether it is a new version of an already known plan of the system, the receiving device storing for example in memory a list of the set known plans and their different versions, or questions one of the devices, eg the server MO, whose function is to maintain such a list. Hereinafter, a "series of plans" corresponds to the set of files consisting of a new plan and its successive updates (or versions).
    According to a first semi-automatic variant, it is left to a user to control the recording of the plan received by the system. In particular, the receiving device has a graphical interface providing the user, at 24, a different recording button for each of the known series of the system, and an additional recording button for recording a new plan. system unknown 10. Buttons with the name of a series allow you to save an additional version, which will in turn become the version considered to be the most up-to-date of this series. The button for saving a new plan is conventionally called "new plan". This button is visually different from the buttons for saving a new version. In the context of this preferred embodiment, it is therefore its graphic charter that differentiates it. By selecting one or the other of the registration buttons, the user identifies the plan submitted to the system as either a completely new plan or the most up-to-date version of a series of plans. In the case of a new plan, it is requested by the receiving device to the user to name this plan, prohibiting, to avoid conflicts, the use of the name of a series already known. The user then freely enters an alphanumeric entry field provided for this purpose. In the case of the new version of a known plan, the name automatically given to this plan is the name of the series. Each plan is thus named in a unique way, its name constituting the identification data of this plan. In both cases, this alphanumeric value is named "PLAN NAME". In the context of this preferred embodiment, the user then loads, at 26, the received plane in PDF format on the server MO.
    According to a second fully automated variant, the receiving device implements the recording function automatically, assigning itself a name to a new plan, and then transmits the PDF source file to the server MO.
    Once this source file, named "DOC PDF", received by the server MO, a software hosted on the latter starts, in 28, by automatically timestamp the loading of this source file, by comparison with the internal clock of the server MO, then the software associates with this file the value "PLAN NAME" as identification data. Each source file is then identified by a couple of data (DATE, NAME_PLAN) unique. When this is done, the server MO automatically converts to 30 the P pages of the PDF source file respectively into P two-dimensional separate matrix images, in PNG image format, each of the P images thus corresponding to one of the pages of the DOC_PDF file. This matrix image will subsequently be called a "master". This master is in particular marked by a unique integer value, for example named "PAGE" specific to the position of this page within the document DOCPDF. For example, PAGE = 1 is set for the first page of the DOCPDF file, PAGE = 2 for the second page of the PDF DOC file, and so on. The conversion of the PDF file into PNG images is for example carried out by means of the "ImagelOUtil.writelmage" function of the "PDF BOX" toolbox installed on the MO server. The resolution of the generated images is known and for example imposed at 100 dpi (for "dot per inch"). In a first variant, the resolution is also known data stored in the devices M1, ..., Mn so that it is not necessary to subsequently communicate it to the devices Ml, ..., Mn. In a second variant, which makes it possible to manage different resolutions, for example from version to version, or even from master to master, this data is stored in each image resulting from the masters as RES metadata, and thus communicated to the devices M1. .., Mn. It should be noted, as is known per se, that the PDF DOC source file usually also includes a native resolution, generally 72 dpi for a PDF file. Also knowing the size in pixels of the masters, the scale of the plane (eg distance between 2 pixels = 1 mm) is known, so that the scale of the plane is also transmitted through the RES resolution. Thus, the resolution RES makes it possible to approximate physical dimensions of the paper plane, from measurements of distances between pixels made on the devices M1,..., Mn.
    In a next step of cutting 32, the software of the server MO first identifies the dimensions, in pixels, of each of the masters. These dimensions are integer values denoted Lm (Width) and Hm (Height). This determination is implemented by computer, for example by means of the "getWidth" and "getHeight" functions of the PDF BOX toolbox. Then, the masters whose at least one of the dimensions Lm or Hm is greater than the dimensions Ld and Hd, constituting the base of minimum characteristics common to the devices M1, ..., Mn, and stored in the server M0, are cut into a set of smaller sub-images, smaller than the dimensions Ld and Hd. On the other hand, the masters, whose two dimensions Lm and Hm are smaller than the dimensions Ld and Hd, are not modified. For this purpose, the server MO performs for example the Euclidean division of the dimension too high of the master by the corresponding dimension Ld or Hd, according to the following relations:
    If Lm> Ld, then the parameters p and r such that Lm = Ld.p + r are computed, where p and r are positive integers and r is strictly less than Ld;
    If Hm> Hd, then the parameters q and 5 such that Hm = Hd.q + s, are calculated, where q and λ are positive integers and 5 is strictly less than Hd.
    The master is then decomposed into (p + 1) times (q + 1) sub-matrix images of the same resolution as the master (eg 100 dpi) and whose dimensions are less than or equal to the characteristic dimensions Ld and Hd. In particular, in the orthonormal frame, denoted R, taking as origin the lower left corner of the master and whose norm is equal to 1 pixel, for i integer varying from 0 to p- and for j integer varying from 0 to q-1 , the subframe SI (i, j) is composed of all the pixels of the master of coordinates (x, y) such that:
    These sub-images SI (i, j) are of height in pixels equal to Hd and of equal width in pixels kLd.
    Still in this same frame R, for i integer varying from 0 to p-1, the subimage SI (i, q) is composed of all the pixels of the master of coordinates (x; y) such that:
    These sub-images S (i, q) are of height in pixels equal to 5 and width in pixels equal to Ld.
    Still in this same frame R, for j integer varying from 0 to q- , the subframe SI (p, j) is composed of all the pixels of the coordinate master (x; y) such that:
    These sub-images S (p, j) are of height in pixels equal to Hd and of width in pixels equal to r.
    Still in this same reference frame R, the sub image SI (p, q) is composed of all the pixels of the coordinate master (x; y) such that:
    This subimage S (p, q) has a height in pixels equal to 5 and a width in pixels equal to r.
    The decomposition of the master in these sub-images is ensured, within the framework of this preferred embodiment, by means of the "drawImage" function of the PDF BOX toolbox. At the end of these steps performed by the server MO, the plane in PDF format, identified by a single pair (DATE, PLAN NAME), is thus decomposed into P masters, themselves decomposed into (p + 1) times ( q + l) matrix subpictures whose resolution is known (100dpi) in the PNG format, and whose dimensions, which are also known, are smaller than the minimum technical dimensions Ld, Hd, of the screens of the devices M1,. min. The server MO thus cuts the initial plane in PDF format into Q raster images stored in a DOCPNG1, ..., DOCPNGQ, for example PNG image format, each uniquely identified by seven parameters (DATE, PLAN NAME, PAGE, i, j, WIDTH, HEIGHT) stored as metadata of the corresponding PNG file, the WIDTH and HEIGHT parameters being respectively the width and the pixel height of the image. These seven parameters, and in particular the parameters PAGE, i and j, uniquely code the position of the matrix image in the plane and are used by the devices M1,..., Mn for the recomposition of the plane. The devices M1,..., Mn memorize the dimensions Ld and Hd for this recomposition or, in another variant, these dimensions are also stored as metadata of the sub-images S1 and thus communicated to the devices M1,. min.
    All the images in the PNG DOC PNG1, ..., DOC PNGQ format, identified by their parameters, are then communicated, at 34, by the server MO to each of the devices Ml, ..., Mn. By their format, they are already assured of being able to view them, a matrix image is indeed usually readable by any conventional computing device.
    Following the reception, in 36, of the series of DOC PNG1, ..., DOC PNGQ images by a computer device Ml, ..., Mn, the latter stores the images received in its mass memory and then sets a recomposition of the cut digital plane.
    More particularly, each device Ml,. . ., Mn embeds a software which makes it possible to reconstitute each master resulting from the DOC PDF source file by juxtaposing the images having the identical triplet (DATE, NAME PLAN, PAGE). Note on this point that the recomposition algorithm described below does not apply any transformation, or image processing, to the images in the series, and consists only of comparisons of integers and the definition of containers. . H can thus be implemented including by computer devices with very limited hardware and software resources.
    More particularly, in a step 38, the computer device M1,..., Mn automatically generates P interpretable objects, faithful to the original P masters, resulting from an intelligent organization of the sub-images from the master by means of a visualization file as described in Figure 2, and more particularly an HTML document that displays the images and navigate between them, and between the different pages, to view the plan. The P objects in question are for example HTML containers of an HTML file, each object being composed of 3 floors, namely composed of: a main container, in which line containers are found; said line containers comprising image containers; said image containers invoking the PNG sub-images stored in the device memory.
    These P objects can be displayed by the destination computing device. As described above, in the particular case of a display using an internet browser, these containers are for example "div" tags and "img" tags.
    In particular, for each set of received images having the same parameter values (DATE, NOMPLAN), but having a different parameter value (PAGE), an interpretable object is created in an HTML DOC HTML document identified by the parameters (DATE, PLAN NAME, PAGE) and recorded by the computing device. To generate the main container of this object, all images with the same parameters (DATE, PLAN NAME, PAGE) are selected. For each value of parameter "i" among the selected images, the sum of the parameters "HEIGHT" of the images having this value "i" is carried out, this sum being denoted H * and which in all logic is equal to the height Hm of the master corresponding. This operation is also performed to calculate a width L * which logically is equal to the width in pixels Lm of the corresponding master. Once the height H * and the width L * of the reconstructed master, a rectangular container, whose height, in pixels, is H * and whose width, in pixels, is L * is generated in the HTML document. This is the main CP container of the object. We denote by R * the orthonormal reference taken from the lower left corner of this container and whose norm is equal to 1 pixel.
    Thus, we have in R * the main container which will contain the set of pixels of coordinates (x; y) such that:
    Inside this main container CP, line containers are then registered. For this, and always working from the group of received images having the same values (DATE, PLAN NAME, PAGE), the computing device identifies the value q * which is the highest positive integer among the values "y ". Logically q * = q. Note that the initial slicing was done in such a way that the images having the same values j also have the same value "height". This value is worth h * = Hd for j integer varying from 0 to q * -1 and .v * =. V for j = q *. For j integer increasing from 0 to q *, the computing device generates a rectangular container of lines C (j) whose width in pixels is worth Z * and whose height is equal to the value "height" of the images having the same value of parameter j. This container C (j) is contained in the main container so that its lower left corner coincides with that of the coordinate pixel (1; j./z * + 1) in R *.
    Thus, we have in R *: - For q *> 0, and for j integer varying from 0 to q * -l, the container of lines C (j) will contain the set of pixels of coordinates (x; y) such than :
    - For j = q *, the line container C (q *) will contain all the coordinate pixels (x; y) such that:
    Inside each of the lines containers C (j), the computing device then incorporates image containers, named CI (i, j). For this, and always working from the group of received images having the same values (DATE, PLAN NAME, PAGE), the computing device identifies the value p * which is the highest positive integer among the values "z" . Logically p * = p. Note that the initial slicing was done in such a way that the images having the same parameter values "/" also have the same value "WIDTH". This value is worth L * = Ld for i integer varying from 0 to p * -1 and r * = r for i = p *. For an integer increasing from 0 to p *, at j fixed, the device therefore generates the rectangular image container CI (i, j) whose height in pixels is equal to the height of the line container C (j), c is either h * or 5 *, and whose width is equal to the value of the parameter "WIDTH" of images of the same i. This container CI (isj) is contained in the line container C (j) so that its lower left corner coincides with that of the coordinate pixel (/'./*+1 Jh * + 1) in R *.
    Thus we have in R *: - For c / *> 0 and p *> 0, for j integer varying from 0 to q * -1, for i integer varying from 0 to p * -1, the image container CI (i, j) comprises all the pixels of the initial master of coordinates (x; y) such that:
    For i = p *, the image container CI (p *, j) comprises all the pixels of the initial master of coordinates (x; y) such that:
    For j = q *, for i integer varying from 0 to p * -1, the image container CI (i, q *) contains all the pixels of the initial master of coordinates (x, y) such that:
    For i = p *, the image container CI (p *, q *) contains all the pixels of the initial master of coordinates (x; y) such that:
    Inside each of the image containers CI (i, j), and always working from the group of received sub-images having the same values (DATE, PLANE_NAME, PAGE), one integrates, by a call to by means of an HTLM tag, for example IMG, the image SI (i, j) stored in the mass memory of the computing device, while keeping in R * the orientation that it had in R and by superimposing the pixel constituting its lower left corner in R to the pixel constituting the lower left corner of CI (i, j) in R *.
    An alternative implementation of this redial protocol is to generate, at the tier 2 container, column containers instead of line containers by working on "i" before working on "j". This variant ultimately leads to Cl (ij) superimposable in R * to CI (i, j) generated in the base case.
    Ultimately, the object thus constituted at the level of the computing device is a faithful representation of the master decomposed by the server MO having the same values (DATE, NOMPLAN, PAGE). Its height H * is equal to Hm, the height of the master of reference; its width L * is equal to Lm, the width of the master of reference. This object is also of the same resolution as the master (in this case: 100dpi).
    Each master leads, for example, to the production of a particular HTML page, and the HTML pages are linked to each other to produce a set of successive pages or else produces a single HTML page recording the P objects and allowing navigation between them. . The starting source file, in PDF format and comprising several pages, is thus transformed into a set of corresponding pages, each consisting of the juxtaposition, during the display on the internet browser at 40, of matrix sub-images corresponding to the division of the initial PDF document page. Moreover, as is known, the user can click on each portion of this reconstructed page (ie each sub-image of the corresponding master) and directly view the image which is displayable in full format because of the dimensions chosen for those based on the lowest common denominator among the screens of the computing devices Ml, ..., Mn.
    In addition, each main container CP is identified by a single triplet (DATE, PLAN NAME, PAGE) which characterizes it. The series of containers is the set of main containers having the same parameter values "PLAN NAME", the name of this series of containers being this value "PLAN NAME".
    The values of the parameters "DATE" and "PLAN NAME" make it possible to differentiate, on each of the computing devices ΜΙ,.,. Μη, the containers generated from the elements of a new plan, those generated from a plan to update a series of plans. For this purpose, and in the context of this preferred embodiment, it has been chosen to compare the value "PLAN NAME" of the main container thus generated with all the names of the series of containers stored in the computer device M1,..., Mn.
    If the value of the "NOMPLAN" parameter of the generated container is different from all the names of the series of containers known to the machine, the container is identified as being one of the pages of a new plan. He becomes the first in a series bearing his name.
    If the value of the "PLAN NAME" parameter of the generated container is identical to that of a series of containers already known to the machine, the container is identified as the most up-to-date version of one of the pages of the plan corresponding to this series. The value "PAGE" of this container is then compared to all the page values of this series of containers. This value "PAGE" is different from all the "PAGE" values of the containers of the series (superior, logically): in this case, the generated container is identified as being a new page of the plan. Either this "PAGE" value is equal to a "PAGE" value that one or more containers in the series have: in this case, the generated container is identified as the most up-to-date version of all containers of the same value "PAGE"" in the series. We can also verify, in the latter case, that the "DATE" value of the generated container is greater than all the "DATE" values of containers of the same value "DATE" in the series.
    According to a variant embodiment of this means of identifying the most up-to-date version of the container constituting one of the pages of a plan, it is possible to ask the operator, at the time of loading of the source file, of assign a version number to the document submitted for registration. This version number can be imposed as being superior to all the version numbers of the already known plans in the same series. Regardless of its loading date, the container having the highest version number among those known to the recipient machine having the same pairs (PLAN NAME, PAGE), are identified, in this case, as being the most important pages. up to date.
    According to another variant embodiment, the determination of the container constituting the most up-to-date page can be done solely by comparison of the "DATE" values of the containers having the same pairs (PLANE_NAME, PAGE).
    Finally, a third variant embodiment that combines both the comparison of the "DATE" and the comparison of the version number would have the advantage of being even more reliable if the communication system used between the devices MO, Ml, .. ., Mn does not allow a permanent synchronous link and if different operators can carry out quasi-simultaneous recordings from two different devices, of the MO server type. This third means of highlighting the most up-to-date version of the searched page makes it possible to obtain a reliable result even if one of the two servers MO is temporarily disconnected from the system, or if one of the two servers MO needs a significantly longer processing time than the first one. We can thus compare the version numbers, to eliminate the duplicates or the errors (case of two operators carrying out a loading, at the same time)
    Ultimately, the recipient machine Ml, ..., Mn is well able to identify the most up-to-date versions of the different pages of plans that are transmitted to it. These plan pages are communicated to it in a format chosen so that they can read and interact with them (here, a format consisting of main containers, containing line containers, containing image containers, containing images).
    It is thus possible to make measurements from this object available on the devices Ml, ..., Mn, especially as if these measurements were made on the server MO itself. These measurements, which are performed with an uncertainty of the order of the pixel (discretization of the image) provide a very good approximation of the physical dimension, which would have been found on the paper print of the source file. At the 1: 1 paper print scale, the following approximation law is thus verified:
    This law, which makes it possible to approximate straight lengths, also makes it possible to approximate, by mathematical extrapolations, curvilinear lengths, surfaces. The set of measurements and annotations are for example stored in a text document that is part of the view file or in a database called by the said file. Thus, in the event of update of a plan, for example the update of a page, this document is always present in the visualization file, and therefore applicable to the updated page.
    It has been described a plan view on devices Ml, Mn based on the production of an HTML document, stored in the mass memory of each device. This makes it possible to recompose the plan on the devices. The invention is however not limited to this type of recomposition and display. In particular, tablets and smartphones allow a dynamic display of images.
    In another preferred embodiment, the containers are organized into Panels, namely: a main panel, in which there are Panels of lines; said line panels comprising picture panels; and - said picture panels invoking the PNG sub-pictures stored in the device memory.
    This embodiment is used for display on terminals of the tablet or smartphone type equipped for example with a Windows operating system. In this case, the commands for displaying sub-images in PNG format are not stored in a materialized file as such, but are simply recorded with a known address, in the RAM of the device. The set of sub-images attributed to an object P constitutes what can be called a "virtual" file. Here, the construction of the graphical interface is managed by the operating system which relies on a C # object created dynamically from the Panel constituting the main container. In particular, such an object is created on the fly based only on the images actually displayed on the screen, and is modified as soon as the user controls the display of at least one other image.
    According to an alternative embodiment, the images corresponding to the oldest versions of plans are deleted from the memory of the computer devices Ml,..., Mn, the latter thus retaining only the most up-to-date version.
    According to an alternative embodiment, when the source file received leads to a division identical to that already made for the last version of the plan, the containers are therefore already appropriate, so that the update consists only of the link change of picture call image containers. In a variant, a simple overwriting of the existing images makes it possible to update the plan while retaining only the updated version.
    According to an alternative embodiment, when the source file received leads to a division identical to that already made for the last version of the plan, the containers are therefore already appropriate, so that the updating consists only in changing the sub-images having is modified from one version to another. The comparison of the sub-images with each other can be performed at the initial machine MO such that only sub-images presenting a modification are then broadcast to the entire system. This embodiment makes it possible to reduce the volume of data to be transferred, to reduce the computing times on the terminals ΜΙ,.,., Μη, and to preserve the memory capacity of the machines.
    According to a variant embodiment of this processing method, all the work performed at a dedicated server MO can be performed on one of the computing devices ΜΙ,.,., Μη on which the source file would be loaded by the user, if this device has the necessary tools, algorithms and computing power. The preparation is then performed once on this machine, and on behalf of all devices ΜΙ,.,., Μη, then broadcast to all other devices. In the context of this variant embodiment, the algorithms remain unchanged, but the starting machine can be a laptop computer powerful enough to be able to perform the processing.
    According to another variant embodiment of this method of processing, part of the work performed at the level of the server MO is carried out on one of the computing devices ΜΙ,.,., Μη on which the source file is loaded by the user, provided that that this device has the tools, the algorithms and the computing power necessary for these first steps of work. These elements, partially processed, are then broadcast to the server MO which finalizes the processing and returns all the image files to all devices ΜΙ,.,., Μη. In the context of this variant embodiment, the starting device may be a portable computer that does not have all the necessary computing power, or that does not benefit from all the software or algorithms necessary for the complete processing of the source file. According to this embodiment, each step described above implemented by the server MO, taken individually, is performed on one or the other of the devices MO, M1,..., Mn, once, and for the count of the set of devices MO, Ml, .. ,, Mn of the system.
    According to an alternative embodiment of the method, the source file loaded by the user can be in DWG (Autocad) format. In this case, the MO server has a toolbox for transforming this source document into one or more PNG pixelated flat images. This toolbox can for example be RealDWG. In this case, the pages of the plan can be the different tabs of the DWG document.
    According to an alternative embodiment of the method, the source file loaded by the user can be a three-dimensional model representing an object constructed or to be constructed. In the context of this variant embodiment, the server MO has a toolbox for extracting flat and pixelated images of this model, possibly by means of a specific graphical interface, available on the server MO and allowing positioning selected cuts.
    权利要求:
    Claims (11)
    [1" id="c-fr-0001]
    A method of displaying a digital plane (PLAN) by computing devices (M1, M2, ... Mn) connected through a computer network (RI) to a server computing device (MO), each computer device (Ml, M2, .. Mn) comprising a computer memory (SSD) for storing at least one computer file (DOC RECOMP), called "visualization", comprising at least one matrix image (SUB PLAN1, SUB PLAN2 ,. SUBPLANQ), identification data (NOMPLAN), and version data (DATE), a DISPLAY, and a processing unit for controlling the screen to display the raster image of the roster file. visualization stored in said memory, the method comprising: by the server computing device (MO): the reception of a computer file (DOCPDF), called "source" coding the digital plane (PLAN); the production, according to the source file (DOC PDF), of at least one computer file (DOC PNG 1, DOC_PNG2, ..., DOC PNGQ), called "intermediate", comprising a matrix image (SUBPLAN1, SUBPL AN2, ..., SUB PLANQ) of at least a portion of the digital plane (PLAN), ID data (PLAN NAME), and version (DATE) data associated with the digital plane (PLAN),; sending each intermediate file to the computing devices; by each computing device (Ml, M2, ..., Mn): receiving and recording each intermediate file (DOCPNG1, DOC_PNG2, ..., DOCPNGQ) sent by the server device (MO); and displaying on the screen (DISPLAY) of the digital plane (PLAN) as a function of the matrix image or images (SUB_PLAN1, SUBPL AN2, ..., SUB_PLANQ) of the intermediate file or files having the identification data (PLAN NAME ) associated with the digital plane (PLAN) and the most recent version data (DATE).
    [2" id="c-fr-0002]
    2. The method of claim 1, wherein each intermediate file comprises data (RES) resolution of the matrix image or the computer device (Ml, M2, ..., Mn) stores the resolution of the matrix image. .
    [3" id="c-fr-0003]
    3. Method according to claim 2, wherein the computing device (Ml, Mn) implements: if a visualization file, having identification data identical to that of the intermediate file received, is stored in the memory of said device updating at least one raster image of said view file according to the raster image of the intermediate file, retaining the identification data of the display file; if no display file, having identification data identical to that of the intermediate computer file, is stored in the memory of said device, the production of a display file comprising the identification, version, and resolution, and the matrix image of the intermediate file, and storing the file produced in the memory of said device.
    [4" id="c-fr-0004]
    The method according to claims 2 and 3, wherein the production of the intermediate file comprises producing the resolution data of the matrix image, and wherein the resolution data of the display file is updated according to the data of the image file. resolving the intermediate file.
    [5" id="c-fr-0005]
    5. Method according to one of claims 1 to 4, wherein the source file (DOC PDF) is a file in a vectorized computer format, including a pdf or autocad file.
    [6" id="c-fr-0006]
    6. Method according to any one of the preceding claims, wherein the computer device (Ml, M2, ..., Mn): - produces and stores an HTML file containing container type tags according to the dimensions of the image matrix and image-type tags linking the stored image to the HTML file; - is configured to display the image by means of an internet browser.
    [7" id="c-fr-0007]
    A method according to any one of the preceding claims, wherein the computing device (M1, M2, ..., Mn) produces a dynamic computer object, stored in a random access memory of the device, comprising image containers incorporating only the raster image (s) displayed on the screen.
    [8" id="c-fr-0008]
    The method as claimed in any one of the preceding claims, wherein the screens (DISPLAY) of the computing devices (M1, M2, Mn) each comprise a matrix of at least L x H display pixels: in which the device forming server (MO): - memorizes the parameters LetH; - cuts the digital plane (PLAN) into a series of matrix images (SUBPLAN1, SUBPLAN2, ..., SUBPLANQ) of dimensions less than or equal to L x H pixels if the numerical plane (PLAN) comprises Lp x Hp pixels with Lp > L and / or Hp> H, and produces an intermediate file for each matrix image of said series; and wherein the computing device (M1, M2, ..., Mn) updates or creates the view file according to the series of images (SUB PLAN1, SUBPLAN2, ..., SUB PLANQ) contained in the intermediate files.
    [9" id="c-fr-0009]
    9. The method of claim 8, wherein the matrix of L x H pixels corresponds to the screen of smaller size among the screens (DISPLAY) of computing devices (Ml, M2, .. Mn).
    [10" id="c-fr-0010]
    Digital plan display computer system (PLAN), comprising computer devices (Ml, M2, ... Mn) connected through a computer network (RI) to a server computing device (MO) each computer device (Ml, M2, ... Mn) comprising a computer memory for storing at least one computer file (DOC RECOMP), called "visualization", comprising at least one matrix image (SUB_PLAN1, SUBPLAN2, ... , SUB_PLANQ), identification data (NOM_PLAN), and version data (DATE), a screen (DISPLAY) and a processing unit for controlling the screen so as to display the matrix image of the stored display file in said memory, the server computing device (MO) being configured for: - the reception of a computer file (DOCPDF), called "source" coding the digital plane (PLAN); the production, according to the source file (DOC PDF), of at least one computer file (DOC_PNG1, DOCPNG2, ..., DOCPNGQ), called "intermediate", comprising a matrix image (SUBPLAN1, SUB PLAN2, .. , SUB_PLANQ) at least part of the digital plane (PLAN), data (NOM_PLAN) identification and version associated with the digital plane (PLAN), and data (RES) resolution of the matrix image; sending each intermediate file to the computing devices; and each computing device (Ml, M2, ..., Mn) being configured for: receiving and storing each intermediate file (DOC_PNG1, DOC PNG2, ..., PNGQ DOC) sent by the server device (MO ); and displaying on the screen (DISPLAY) of the digital plane (PLAN) as a function of the matrix image or images (SUB_PLAN1, SUBPL AN2, ..., SUB_PLANQ) of the intermediate file or files having the identification data (PLAN NAME ) associated with the digital plane (PLAN) and the most recent version data (DATE).
    [11" id="c-fr-0011]
    11. System according to claim 10, able to implement a method according to any one of claims 2 to 9.
    类似技术:
    公开号 | 公开日 | 专利标题
    AU2009286145B2|2012-06-21|Architectures and methods for creating and representing time-dependent imagery
    US10922339B2|2021-02-16|Portable globe creation for a geographical information system
    US20190347270A1|2019-11-14|Server implemented geographic information system with graphical interface
    AU2015204742B2|2017-03-23|Methods for generating an activity stream
    US20140372427A1|2014-12-18|Real-time analytic report analysis and retrieval framework
    WO2011106415A2|2011-09-01|Portable globe creation for a geographical information system
    US20160371080A1|2016-12-22|Application building blocks for on demand and on premise usage
    FR3043806A1|2017-05-19|METHOD FOR VISUALIZATION OF A PLAN BY COMPUTING DEVICES
    WO2012116172A1|2012-08-30|Methods and systems for browsing heterogeneous map data
    US20200327710A1|2020-10-15|Interface to index and display geospatial data
    JP2015061167A5|2016-10-27|
    FR3077662A1|2019-08-09|METHOD OF PROCESSING A VIEW OF A DIGITAL PLAN
    CN105808603A|2016-07-27|Picture management method and device
    CN110119386A|2019-08-13|Data processing method, data processing equipment, medium and calculating equipment
    CN111597290B|2020-10-30|Method and device for transmitting knowledge map and GIS map data, storage medium and equipment
    Bobowski2012|Easy Recording System: Solutions Based on Web Free Apps Databases
    US20150026218A1|2015-01-22|System and Method for Automated Document Linking
    CN112069274A|2020-12-11|Distributed image slice processing method
    Yershov et al.2012|Using concatenated steganography for visual analysis in GIS SOA
    FR3081060A1|2019-11-15|METHOD FOR MANAGING ANNOTATIONS OF A DIGITAL PLAN
    EP3146510A1|2017-03-29|Method for the customisation of a customisable object for a client/server system; and associated information-recording support and client/server system
    WO2002103980A2|2002-12-27|Method and system for broadcasting digital images
    同族专利:
    公开号 | 公开日
    FR3043806B1|2018-10-05|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20070046698A1|2003-08-07|2007-03-01|Gi-Seon Nam|Method for displaying high resolution picture in mobile communication terminal, mobile communication terminal and system for converting picture file format therefor|
    US20100316302A1|2005-09-22|2010-12-16|Google, Inc., A Delaware Corporation|Adaptive Image Maps|
    US20080162635A1|2007-01-03|2008-07-03|Interwise Ltd.|Method and apparatus for participating in a conference session over a data communication network|
    US20120005301A1|2010-06-30|2012-01-05|Skype Limited|Sharing an image|
    US20140002504A1|2012-06-28|2014-01-02|Microsoft Corporation|Generation based update system|FR3077662A1|2018-02-02|2019-08-09|Bluepad|METHOD OF PROCESSING A VIEW OF A DIGITAL PLAN|
    FR3083347A1|2018-06-27|2020-01-03|Bluepad|METHOD FOR SELECTING A POINT ON A MAP OR A MAP DISPLAYED ON A TOUCH DISPLAY DEVICE AND TOUCH DISPLAY DEVICE|
    FR3095060A1|2019-04-10|2020-10-16|Bluepad|Data exchange method through an intermittent network and system implementing the method|
    法律状态:
    2016-10-07| PLFP| Fee payment|Year of fee payment: 2 |
    2017-05-19| PLSC| Publication of the preliminary search report|Effective date: 20170519 |
    2017-10-14| PLFP| Fee payment|Year of fee payment: 3 |
    2018-10-15| PLFP| Fee payment|Year of fee payment: 4 |
    2019-10-31| PLFP| Fee payment|Year of fee payment: 5 |
    2020-11-07| PLFP| Fee payment|Year of fee payment: 6 |
    2021-01-29| PLFP| Fee payment|Year of fee payment: 7 |
    2022-02-15| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1561026|2015-11-17|
    FR1561026A|FR3043806B1|2015-11-17|2015-11-17|METHOD FOR VISUALIZATION OF A PLAN BY COMPUTING DEVICES|FR1561026A| FR3043806B1|2015-11-17|2015-11-17|METHOD FOR VISUALIZATION OF A PLAN BY COMPUTING DEVICES|
    [返回顶部]