FR3043806A1 - Procede de visualisation d'un plan par des dispositifs informatiques - Google Patents

Procede de visualisation d'un plan par des dispositifs informatiques Download PDF

Info

Publication number
FR3043806A1
FR3043806A1 FR1561026A FR1561026A FR3043806A1 FR 3043806 A1 FR3043806 A1 FR 3043806A1 FR 1561026 A FR1561026 A FR 1561026A FR 1561026 A FR1561026 A FR 1561026A FR 3043806 A1 FR3043806 A1 FR 3043806A1
Authority
FR
France
Prior art keywords
file
plan
image
computer
display
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.)
Granted
Application number
FR1561026A
Other languages
English (en)
Other versions
FR3043806B1 (fr
Inventor
Loic Cueroni
Michel Kuehn
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to FR1561026A priority Critical patent/FR3043806B1/fr
Publication of FR3043806A1 publication Critical patent/FR3043806A1/fr
Application granted granted Critical
Publication of FR3043806B1 publication Critical patent/FR3043806B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/14Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G06F3/1423Digital output to display device ; Cooperation and interconnection of the display device with other functional units controlling a plurality of local displays, e.g. CRT and flat panel display
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2340/00Aspects of display data processing
    • G09G2340/14Solving problems related to the presentation of information to be displayed
    • G09G2340/145Solving problems related to the presentation of information to be displayed related to small screens
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2370/00Aspects of data communication
    • G09G2370/02Networking aspects
    • G09G2370/027Arrangements and methods specific for the display of internet documents

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un procédé de visualisation d'un plan numérique (PLAN) par des dispositifs informatiques (M1, M2,...Mn), connectés au travers d'un réseau (RI) à un serveur (M0), chaque dispositif (M1, M2,...Mn) mémorisant au moins un fichier de visualisation, comprenant une image matricielle, des données d'identification, et des données de version, un écran (DISPLAY) et une unité de traitement pour afficher sur l'écran l'image du fichier de visualisation, le procédé comprenant : par le serveur (M0) : - la réception d'un fichier source du plan ; - la production, en fonction du fichier source, d'au moins un fichier intermédiaire, comprenant une image matricielle d'au moins une partie du plan, des données d'identification et données de version associées au plan ; l'envoi de chaque fichier intermédiaire aux dispositifs ; par chaque dispositif (M1, M2,..., Mn) : - l'enregistrement de chaque fichier intermédiaire; - et l'affichage sur l'écran (DISPLAY) du plan en fonction du ou des images matricielles du ou des fichiers intermédiaires ayant les données d'identification associées au plan et les données de version les plus récentes.

Description

PROCEDE DE VISUALISATION D’UN PLAN PAR DES DISPOSITIFS INFORMATIQUES
Domaine de l’invention L’invention a trait au domaine de la gestion informatique de plans numériques, et plus généralement de dessins techniques. L’invention trouve particulièrement application à la visualisation de plans par une flotte de dispositifs informatiques, e.g. ordinateurs portables, tablettes tactiles, smartphones, mis à disposition d’utilisateurs se déplaçant sur site, notamment des dispositifs informatiques mobiles et/ou différents.
Etat de la technique
Un plan, ou plus généralement un dessin technique, est par nature un document particulier : il s’agit de la modélisation graphique ou schématique, d’un objet ou d’un système (e.g. immeubles, villes, machines, etc ), existant ou à créer, qui est caractérisé par un certain nombre d’informations que sont, par exemple, son numéro de mise à jour (usuellement nommé « version »), son nom, son échelle, ses cotations et son orientation. Des informations contextuelles, dépendant de la finalité d’utilisation du plan, sont également associées au plan, comme par exemple des notations, des mesures de distances sur le plan, etc. L’ensemble de ces informations, le plan en lui-même qui correspond à une image numérique, c’est-à-dire la version numérique d’un plan papier, et les informations qui lui sont associées, peuvent prendre informatiquement plusieurs formats (e.g. pdf - « portable document format », DWG - associé au logiciel autoCAD©, etc.) en fonction des souhaits de l’utilisateur et/ou des logiciels à sa disposition pour produire un fichier informatique codant le plan et ses informations associées.
Il est connu d’utiliser des plans ou des dessins techniques au sein de dispositifs informatiques mobiles collaboratifs mis à disposition de collaborateurs d’une entreprise, comme par exemple les dispositifs informatiques dits de « levée de réserves » utilisés dans l’industrie de la construction pour générer des listes de tâches à réaliser et pour faciliter le suivi de l’activité. Ces dispositifs sont généralement constitués de n machines [Ml,..., Mn] (tablettes tactiles, ordinateurs portables, téléphones portables, serveurs), communiquant entre elles au moyen d’un réseau de télécommunication, qui peut être par exemple de type EDGE, 3G, 4G ou Wifi, et hébergeant chacune un logiciel permettant aux utilisateurs de générer des informations en interaction avec les pages d’un plan les plus à jour que connaît le système. Les plans constituent pour ces dispositifs des données d’entrées indispensables à leur bon fonctionnement. La prise en charge de ces plans ne consiste pas à simplement sauvegarder les données qu’ils contiennent, mais nécessite généralement la mise en œuvre d’une procédure plus ou moins complexe selon les cas, visant à préparer les plans de manière à les rendre exploitables par les dispositifs.
Le problème de l’enregistrement des plans, dans de tels dispositifs, est qu’on ne connaît a priori pas les caractéristiques techniques de ces dispositifs (e.g. leurs ressources matérielles et logicielles), qui seront vraisemblablement différentes, et même plutôt limitées dans le cas des terminaux mobiles, notamment de type tablettes tactiles ou smartphones. On ne sait pas non plus a priori quelles seront la complexité et la taille des plans soumis aux dispositifs. Ces incertitudes rendent difficile, voire impossible, la mise en œuvre d’un traitement automatisé des plans qui soit efficace, notamment leur enregistrement. Ainsi, on ne sait pas dire, a priori, si un dispositif recevant un plan est en capacité de traiter convenablement le format informatique utilisé et/ou la taille en pixels de ce plan (la puissance de calcul est-elle suffisante ? le dispositif est-il doté des bons algorithmes ?). Une solution palliative consiste à faire intervenir un opérateur humain au niveau d’un des dispositifs. Cet opérateur lit le plan et effectue manuellement le travail préparatoire de manière à créer un ensemble de fichiers informatiques et de données interprétables par les dispositifs informatiques. Cette solution, coûteuse, nécessite donc de faire intervenir un opérateur humain à chaque nouveau plan, et à chaque nouvelle version d’un plan. En particulier, lorsqu’un plan est mis à jour, un travail conséquent doit être réalisé par l’opérateur pour garantir que les informations associées à l’ancienne version du plan (mesures, annotations, etc.) soient réutilisables pour la nouvelle version du plan. Souvent, cette opération est si coûteuse que ces informations sont tout simplement non réutilisées. D’une certaine manière, il n’existe donc pas de « version » de plan à proprement parler, une nouvelle version de plan étant plutôt traitée comme un nouveau plan.
Expose de l’invention
Le but de la présente invention est de proposer un procédé de traitement d’un plan numérique qui permette une prise en charge du plan par les dispositifs au moyen de ressources matérielles et logicielles limitées, tout en permettant une mise à jour des plans sans perte d’informations. A cet effet, l’invention a pour objet un procédé de visualisation d’un plan numérique par des dispositifs informatiques, connectés au travers d’un réseau informatique à un dispositif informatique formant serveur, chaque dispositif informatique comprenant une mémoire informatique pour mémoriser au moins un fichier informatique, dit « de visualisation », comprenant au moins une image matricielle, des données d’identification, et des données de version, un écran et une unité de traitement pour piloter l’écran de manière à afficher l’image matricielle du fichier de visualisation mémorisé dans ladite mémoire, le procédé comprenant : par le dispositif informatique formant serveur : la réception d’un fichier informatique, dit « de source », codant le plan numérique ; la production, en fonction du fichier source, d’au moins un fichier informatique, dit « intermédiaire », comprenant une image matricielle d’au moins une partie du plan numérique, des données d’identification et de version associées au plan numérique, et des données de résolution de l’image matricielle ; - l’envoi de chaque fichier intermédiaire aux dispositifs informatiques ; par chaque dispositif informatique : la réception et l’enregistrement de chaque fichier intermédiaire envoyé par le dispositif formant serveur; et l’affichage sur l’écran du plan numérique en fonction du ou des images matricielles du ou des fichiers intermédiaires ayant les données d’identification associées au plan numérique et les données de version les plus récentes.
Comme cela est connu, un fichier informatique est une collection d'informations numériques réunies sous un même nom, enregistrées sur un support de stockage informatique et manipulées comme une unité. De même, une image matricielle, ou « carte de points » (de l'anglais « bitmap »), est une image constituée d'une matrice de points, usuellement colorés ou en niveau de gris, c'est-à-dire, constituée d'un tableau, d'une grille, etc., où chaque case possède une valeur de couleur ou de niveau de gris qui lui est propre et est considérée comme un point de l’image. Il s'agit donc d'une juxtaposition de points de couleurs ou de niveau de gris formant, dans leur ensemble, une image.
En d’autres termes, l’invention prévoit un dispositif supplémentaire gérant de manière centralisée les plans. A la différence des dispositifs informatiques usuels, ce dispositif central formant serveur est conçu pour posséder les ressources matérielles et logicielles suffisantes afin de gérer différents format informatiques pour les plans, et convertit automatiquement le fichier informatique source d’un plan en une ou plusieurs images matricielles, tout en produisant en parallèle les données associées à ce plan. Comme cela est connu une image matricielle (par exemple mémorisée sous un format « image », e.g. PNG, JPEG, etc.) est un objet informatique que peut gérer l’essentiel des dispositifs informatiques connus, et ce au travers d’un nombre important de logiciels ou applications (e.g. un navigateur internet), dont au moins un est systématiquement installé dans tout dispositif informatique. Non seulement, l’image matricielle est un objet informatique simple à gérer, mais en outre il permet des annotations et des mesures simples, et offre donc une interactivité simple avec l’utilisateur d’un dispositif informatique. Ensuite, le format de visualisation consiste en une séparation claire entre le contenu visualisé, i.e. la ou les images matricielles constituant le plan numérique, et les données associées au plan. Ainsi, pour la mise à jour du plan, il suffit de mettre à jour les images matricielles du fichier de visualisation associé. Comme par ailleurs, le plan est codé sous forme d’images matricielles, les informations associées au plan, telles que les mesures ou annotations, restent valables, et sont donc aisément re-utilisées, soit directement, soit après une transformation très simple, sur la nouvelle version du plan.
Selon un mode de réalisation de l’invention, chaque fichier intermédiaire comprend des données de résolution de l’image matricielle ou le dispositif informatique mémorise la résolution de l’image matricielle. .
Plus particulièrement, le dispositif informatique met en œuvre : si un fichier de visualisation, ayant des données d’identification identiques à celles du fichier intermédiaire reçu, est mémorisé dans la mémoire dudit dispositif, la mise à jour d’au moins une image matricielle dudit fichier de visualisation en fonction de l’image matricielle du fichier intermédiaire, en conservant les données d’identification du fichier de visualisation ; si aucun fichier de visualisation, ayant des données d’identification identiques à celles du fichier informatique intermédiaire, n’est mémorisé dans la mémoire dudit dispositif, la production d’un fichier de visualisation comprenant les données d’identification, de version, et de résolution, et l’image matricielle du fichier intermédiaire, et la mémorisation du fichier produit dans la mémoire dudit dispositif.
Notamment, la production du fichier intermédiaire comporte la production de données de résolution de l’image matricielle, et dans lequel les données de résolution du fichier de visualisation sont mises à jour en fonction des données de résolution du fichier intermédiaire.
Selon un mode de réalisation, le fichier source est un fichier selon un format informatique vectorisé, notamment un fichier pdf ou autocad.
Selon un mode de réalisation, le dispositif informatique : - produit et mémorise un fichier HTML contenant des balises de type conteneurs en fonction des dimensions de l’image matricielle et des balises de type image liant l’image mémorisée au fichier HTML ; - est configuré pour afficher l’image au moyen d’un navigateur internet.
Selon un mode de réalisation, le dispositif informatique produit un objet informatique dynamique, mémorisé dans une mémoire vive du dispositif, comprenant des conteneurs d’images incorporant uniquement la ou les images matricielles affichées sur l’écran.
Selon un mode de réalisation, les écrans des dispositifs informatiques comprennent chacun une matrice d’au moins de L x H pixels d’affichage : et le dispositif formant serveur : - mémorise les paramètres LetH ; découpe le plan numérique en une série d’images matricielles de dimensions inférieures ou égales à L x H pixels si le plan numérique comporte Lp x Hp pixels avec Lp> L et/ou Hp > H, et produit un fichier intermédiaire pour chaque image matricielle de ladite série ; et le dispositif informatique met à jour ou crée le fichier de visualisation en fonction de la série d’images contenue dans les fichiers intermédiaires.
Notamment, la matrice deL x H pixels correspond à l’écran de plus petite taille parmi les écrans des dispositifs informatiques. L’invention a également pour objet un système informatique de visualisation d’un plan numérique, comprenant des dispositifs informatiques, connectés au travers d’un réseau informatique à un dispositif informatique formant serveur, chaque dispositif informatique comprenant une mémoire informatique pour mémoriser au moins un fichier informatique, dit « de visualisation », comprenant au moins une image matricielle, des données d’identification, et des données de version, un écran et une unité de traitement pour piloter l’écran de manière à afficher l’image matricielle du fichier de visualisation mémorisé dans ladite mémoire, le dispositif informatique formant serveur étant configuré pour : la réception d’un fichier informatique, dit « de source », codant le plan numérique ; la production, en fonction du fichier source, d’au moins un fichier informatique, dit « intermédiaire », comprenant une image matricielle d’au moins une partie du plan numérique, des données d’identification et de version associées au plan numérique, et des données de résolution de l’image matricielle ; l’envoi de chaque fichier intermédiaire aux dispositifs informatiques ; et chaque dispositif informatique étant configuré pour : la réception et l’enregistrement de chaque fichier intermédiaire envoyé par le dispositif formant serveur ; - et l’affichage sur l’écran du plan numérique en fonction du ou des images matricielles du ou des fichiers intermédiaires ayant les données d’identification associées au plan numérique et les données de version les plus récentes.
Ce système est apte à mettre en œuvre un procédé du type précité.
BREVE DESCRIPTION DES FIGURES L’invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple, et faite en relation avec les dessins annexés, dans lesquels des références identiques désignent des éléments identiques ou analogues, et dans lesquels : la figure 1 est une vue schématique d’un système informatique selon l’invention de traitement et de visualisation d’un plan numérique ; - la figure 2 est une vue schématique des données constitutives d’un fichier de visualisation selon l’invention ; et - la figure 3 est un organigramme d’un procédé de traitement et de visualisation d’un plan selon l’invention.
Description detaillee de l’invention
En se référant à la figure 1, un système 10 selon l’invention comporte une pluralité de dispositifs informatiques Ml, M2, ..., Mn équipés chacun d’un processeur, d’une mémoire vive, d’une mémoire de stockage de masse, d’un écran d’affichage et d’un module de communication avec au moins un réseau de communication informatique RI, par exemple un réseau de communication sans fil de type WIFI, EDGE, 3G, 4G, etc., et embarquent chacun un système d’exploitation pour la gestion des différents éléments matériels et logiciels embarqués. Chaque dispositif embarque également un logiciel capable de prendre en charge des fichiers ou objets dit de « visualisation », tels que décrit ci-dessous. Par exemple, les dispositifs Ml, M2, ..., Mn sont des tablettes tactiles, des ordinateurs portables et/ou des smartphones, constituant une flotte de dispositifs portables à usage de collaborateurs dans le domaine de la construction, de la maintenance, des travaux, de la gestion immobilière, de l’entretien de voiries ou de réseaux, ou plus généralement de tout métier nécessitant l’intervention sur site d’équipes techniques mobiles appartenant éventuellement à des structures ou à des entreprises différentes. Les dispositifs Ml, M2, ..., Mn peuvent être identiques, ou différents comme cela est usuellement le cas. Les dispositifs sont notamment différents dans le cas de figure où des entreprises différentes sont amenées à travailler ensemble et à échanger de l’information sur un même projet. Ces entreprises n’ont pas nécessairement le même matériel informatique à disposition (hétérogénéité des machines Ml,.. ,,Mn).
Le système 10 comporte également un dispositif central MO, par exemple serveur UNIX, apte à communiquer avec chaque dispositif Ml, M2, ..., Mn au travers du réseau RI, via par exemple une application de type WEB développée en JAVA. Le serveur MO dispose de ressources matérielles et logicielles appropriées pour traiter différents types de formats informatiques sous lesquels un plan peut être mémorisé, comme par exemple des fichiers vectorisés du type PDF (pour « portable document format ») ou DWG (format informatique du logiciel autoCAD®).
La figure 2 illustre un exemple de fichier informatique de visualisation de plan enregistré dans la mémoire de chaque dispositif Ml, M2,..., Mn. Le fichier de visualisation constitué : d’un premier fichier DOC HTML ayant des métadonnées META, comportant des données d’identification ID identifiant de manière unique le plan et des données de version DATE identifiant de manière unique la version du plan, ainsi qu’une portion HTML comportant un ensemble de conteneurs, par exemple définis par des balises DIV, reliés à des images, par exemple au moyen de balises IMG ; - de seconds fichiers informatiques de type image DOC PNGl,...DOC_PNGP, par exemple au format PNG (pour « portable network graphie »), constituant un découpage du plan numérique. Chaque fichier image comporte des métadonnées classiques META1 (e.g. l’entête IHDR d’un format PNG comprenant la hauteur et la largeur de l’image), un bloc de données pixels constituant une image, ainsi que des métadonnées META2 propres à l’invention, comportant notamment des données (RES) de résolution de l’image et des données (POS) de position de l’image dans le plan, ainsi que les données d’identification (ID) et de version (DATE) du plan ; - un troisième fichier DOC_TXT comprenant l’ensemble des mesures et annotations réalisées sur le plan au moyen du dispositif, et enregistrées par exemple dans un format texte.
Comme il sera décrit ci-après, la lecture du fichier DOC HTML dans un navigateur internet permet de recomposer le plan numérique en affichant les images matricielles mémorisées dans les fichiers DOC_PNGl,...DOC_PNGQ, ainsi que les mesures et annotations contenues dans le fichier DOCTXT.
Il va à présent être décrit un mode de réalisation d’un procédé de traitement et de visualisation de plan numérique selon l’invention, illustré à titre d’exemple en relation avec un fichier source de type PDF comportant P pages, P étant un entier supérieur ou égal à 1. Le format PDF est usuellement utilisé pour la communication de plans entre dispositifs informatiques. Toutefois, en raison de sa nature vectorielle, l’affichage d’un fichier PDF nécessite des ressources matérielles importantes, les opérations d’agrandissement et de réduction d’une image vectorielle étant par exemple très longues sur des dispositifs de type tablette tactile ne disposant pas d’un processeur puissant et d’une mémoire RAM conséquente.
Le procédé selon l’invention comporte deux ensembles principaux de traitements informatiques, un premier ensemble de traitement étant mis en œuvre par le serveur MO, capable d’interpréter des fichiers PDF, e.g. grâce à une boite à outils telle que PDF BOX disponible sous licence Apache 2.O., et un second ensemble de traitements étant mis en œuvre par chaque dispositif Ml, M2,..., Mn. Le premier ensemble de traitements est avantageusement optimisé en fonction des capacités d’affichage des dispositifs Ml, M2,. . ., Mn. Plus particulièrement, un plan numérique de grandes dimensions en pixels est découpé en images matricielles de même dimensions, ou plus petites, que les dimensions Ld (largeur) et Hd (hauteur) en pixels du plus petit écran parmi les écrans des dispositifs Ml, M2,..., Mn. Ainsi, chaque dispositif est capable d’afficher en plein format chaque image matricielle produite par le serveur MO. Le second ensemble de traitements consiste à recombiner les images matricielles dans un fichier de visualisation de manière à afficher le plan numérique sur les écrans des dispositifs Ml, M2,..., Mn.
En se référant à l’organigramme de la figure 3, le procédé débute, en 20, par la réception par le système 10 d’un fichier DOC PDF au format PDF codant un plan numérique, ce fichier pouvant être reçu par l’un des dispositifs Ml, M2,..., Mn ou par le serveur MO. En 22, le dispositif récepteur détermine si le plan soumis est un plan nouveau ou s’il s’agit d’une nouvelle version d’un plan déjà connu du système, le dispositif récepteur stockant par exemple en mémoire une liste de l’ensemble des plans connus et de leurs différentes versions, ou bien interroge l’un des dispositifs, e.g. le serveur MO, ayant pour fonction de tenir à jour une telle liste. Ci-après, une « série de plans » correspond à l’ensemble des fichiers constitués d’un plan nouveau et de ses mises à jour successives (ou versions).
Selon une première variante semi-automatique, il est laissé la possibilité à un utilisateur de contrôler l’enregistrement du plan reçu par le système. Notamment, le dispositif récepteur dispose d’une interface graphique proposant à l’utilisateur, en 24, un bouton d’enregistrement différent pour chacune des séries connues du système, et un bouton d’enregistrement supplémentaire permettant l’enregistrement d’un plan nouveau inconnu du système 10. Les boutons portant le nom d’une série permettent d’enregistrer une version supplémentaire, qui deviendra à son tour la version considérée comme étant la plus à jour de cette série. Le bouton permettant l’enregistrement d’un plan nouveau est appelé par convention « nouveau plan ». Ce bouton est visuellement différent des boutons permettant d’enregistrer une nouvelle version. Dans le cadre de cette variante de réalisation préférée, c’est donc sa charte graphique qui le différencie. En sélectionnant l’un ou l’autre des boutons d’enregistrement, l’utilisateur identifie le plan soumis au système comme étant soit un plan totalement nouveau, soit la nouvelle version la plus à jour d’une série de plans. Dans le cas d’un plan nouveau, il est demandé par le dispositif récepteur à l’utilisateur de nommer ce plan, en interdisant, pour éviter les conflits, l’emploi du nom d’une série déjà connue. L’utilisateur renseigne alors librement un champ de saisie alphanumérique prévu à cet effet. Dans le cas de la nouvelle version d’un plan connu, le nom automatiquement donné à ce plan est le nom de la série. Chaque plan est ainsi nommé de manière unique, son nom constituant la donnée d’identification de ce plan. Dans les deux cas, cette valeur alphanumérique est nommée « NOM PLAN ». Dans le cadre de cette réalisation préférée, l’utilisateur charge ensuite, en 26, le plan reçu au format PDF sur le serveur MO.
Selon une seconde variante entièrement automatisée, le dispositif récepteur met en œuvre la fonction d’enregistrement de manière automatique, en attribuant lui-même un nom à un nouveau plan, puis transmet le fichier source PDF au serveur MO.
Une fois ce fichier source, nommé « DOC PDF », reçu par le serveur MO, un logiciel hébergé sur ce dernier commence, en 28, par horodater automatiquement le chargement de ce fichier source, par comparaison avec l’horloge interne du serveur MO, puis le logiciel associe à ce fichier la valeur « NOM PLAN » en tant que donnée d’identification. Chaque fichier source est alors identifié par un couple de données (DATE, NOM_PLAN) unique. Ceci étant fait, le serveur MO convertit automatiquement en 30, les P pages du fichier source PDF respectivement en P images matricielles bidimensionnelles distinctes, au format image PNG, chacune des P images correspondant donc à l’une des pages du fichier DOC_PDF. On appellera par la suite cette image matricielle un « master ». Ce master est en particulier repéré par une valeur entière unique, par exemple nommée « PAGE » propre à la position de cette page au sein du document DOCPDF. Par exemple, il est fixé PAGE=1 pour la première page du fichier DOCPDF, PAGE =2 pour la deuxième page du fichier DOC PDF, etc. La conversion du fichier PDF en images PNG est par exemple réalisée au moyen de la fonction « ImagelOUtil.writelmage » de la boite à outils « PDF BOX » installée sur le serveur MO. La résolution des images générées est connue et par exemple imposée à 100 dpi (pour « dot per inch »). Dans une première variante, la résolution est également une donnée connue mémorisée dans les dispositifs Ml,..., Mn de sorte qu’il n’est pas nécessaire de communiquer ultérieurement celle-ci aux dispositifs Ml,..., Mn. Dans une seconde variante, permettant notamment de gérer des résolutions différentes, par exemple de version en version, voire de master en master, cette donnée est mémorisée dans chaque image issue des masters en tant que métadonnée RES, et donc communiquée aux dispositifs Ml,..., Mn. On notera, comme cela est connu en soi, que le fichier source DOC PDF comprend usuellement également une résolution native, généralement 72 dpi pour un fichier PDF. Connaissant par ailleurs la taille en pixels des masters, l’échelle du plan (e.g. distance entre 2 pixels = 1 mm) est donc connue, de sorte que l’échelle du plan est transmise également au travers de la résolution RES. Ainsi, la résolution RES permet d’approximer des dimensions physiques du plan papier, à partir de mesures de distances entre pixels effectuées sur les dispositifs Ml,..., Mn.
Dans une étape 32 de découpage suivante, le logiciel du serveur MO identifie tout d’abord les dimensions, en pixels, de chacun des masters. Ces dimensions sont des valeurs entières notées Lm (Largeur) et Hm (Hauteur). Cette détermination est mise en œuvre informatiquement au moyen par exemple des fonctions « getWidth » et « getHeight » de la boite à outil PDF BOX. Puis, les masters dont au moins l’une des dimensions Lm ou Hm est supérieure aux dimensions Ld et Hd, constituant le socle de caractéristiques minimales communes aux dispositifs Ml,..., Mn, et mémorisées dans le serveur MO, sont découpés en un ensemble de sous-images plus petites, de dimensions inférieures aux dimensions Ld et Hd. Par contre, les masters, dont les deux dimensions Lm et Hm sont inférieures aux dimensions Ld et Hd, ne sont pas modifiés. A cet effet, le serveur MO effectue par exemple la division euclidienne de la dimension trop élevée du master par la dimension Ld ou Hd correspondante, selon les relations suivantes :
Si Lm>Ld, alors les paramètres p et r tels que Lm = Ld.p + r sont calculés, où p et r sont des entiers positifs et r est strictement inférieur à Ld ;
Si Hm>Hd, alors les paramètres q et 5 tels que Hm = Hd.q + s, sont calculés, où q et λ sont des entiers positifs et 5 est strictement inférieur à Hd.
Le master est ensuite décomposés en (p+1) fois (q+1) sous-images matricielles de même résolution que le master (e.g. 100 dpi) et dont les dimensions sont inférieures ou égales aux dimensions caractéristiques Ld et Hd. Notamment, dans le repère orthonormé, noté R, prenant pour origine le coin inférieur gauche du master et dont la norme est égale à 1 pixel, pour i entier variant de 0 à p-\ et pour j entier variant de 0 à q-1, la sous image SI(i,j) est composée de l’ensemble des pixels du master de coordonnées (x ;y) tels que :
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.

Claims (11)

  1. REVENDICATIONS
    1. Procédé de visualisation d’un plan numérique (PLAN) par des dispositifs informatiques (Ml, M2,...Mn), connectés au travers d’un réseau informatique (RI) à un dispositif informatique formant serveur (MO), chaque dispositif informatique (Ml, M2,..Mn) comprenant une mémoire informatique (SSD) pour mémoriser au moins un fichier informatique (DOC RECOMP), dit « de visualisation », comprenant au moins une image matricielle (SUB PLAN1, SUB PLAN2,. . ., SUBPLANQ), des données (NOMPLAN) d’identification, et des données de version (DATE), un écran (DISPLAY) et une unité de traitement pour piloter l’écran de manière à afficher l’image matricielle du fichier de visualisation mémorisé dans ladite mémoire, le procédé comprenant : par le dispositif informatique formant serveur (MO) : la réception d’un fichier informatique (DOCPDF), dit « de source », codant le plan numérique (PLAN) ; la production, en fonction du fichier source (DOC PDF), d’au moins un fichier informatique (DOC PNG 1, DOC_PNG2, ..., DOC PNGQ), dit «intermédiaire», comprenant une image matricielle (SUBPLAN1, SUBPL AN2,..., SUB PLANQ) d’au moins une partie du plan numérique (PLAN), des données (NOM PLAN) d’identification et données (DATE) de version associées au plan numérique (PLAN), ; l’envoi de chaque fichier intermédiaire aux dispositifs informatiques ; par chaque dispositif informatique (Ml, M2, ..., Mn) : la réception et l’enregistrement de chaque fichier intermédiaire (DOCPNGl, DOC_PNG2, ..., DOCPNGQ) envoyé par le dispositif formant serveur (MO); et l’affichage sur l’écran (DISPLAY) du plan numérique (PLAN) en fonction du ou des images matricielles (SUB_PLAN1, SUBPL AN2,..., SUB_PLANQ) du ou des fichiers intermédiaires ayant les données d’identification (NOM PLAN) associées au plan numérique (PLAN) et les données de version (DATE) les plus récentes.
  2. 2. Procédé selon la revendication 1, dans lequel chaque fichier intermédiaire comprend des données (RES) de résolution de l’image matricielle ou le dispositif informatique (Ml, M2, ..., Mn) mémorise la résolution de l’image matricielle. .
  3. 3. Procédé selon la revendication 2, dans lequel le dispositif informatique (Ml, Mn) met en œuvre : - si un fichier de visualisation, ayant des données d’identification identiques à celles du fichier intermédiaire reçu, est mémorisé dans la mémoire dudit dispositif, la mise à jour d’au moins une image matricielle dudit fichier de visualisation en fonction de l’image matricielle du fichier intermédiaire, en conservant les données d’identification du fichier de visualisation ; si aucun fichier de visualisation, ayant des données d’identification identiques à celles du fichier informatique intermédiaire, n’est mémorisé dans la mémoire dudit dispositif, la production d’un fichier de visualisation comprenant les données d’identification, de version, et de résolution, et l’image matricielle du fichier intermédiaire, et la mémorisation du fichier produit dans la mémoire dudit dispositif.
  4. 4. Procédé selon les revendications 2 et 3, dans lequel la production du fichier intermédiaire comporte la production de données de résolution de l’image matricielle, et dans lequel les données de résolution du fichier de visualisation sont mises à jour en fonction des données de résolution du fichier intermédiaire.
  5. 5. Procédé selon l’une des revendications 1 à 4, dans lequel le fichier source (DOC PDF) est un fichier selon un format informatique vectorisé, notamment un fichier pdf ou autocad.
  6. 6. Procédé selon l’une quelconque des revendications précédentes, dans lequel le dispositif informatique (Ml, M2, ..., Mn) : - produit et mémorise un fichier HTML contenant des balises de type conteneurs en fonction des dimensions de l’image matricielle et des balises de type image liant l’image mémorisée au fichier HTML ; - est configuré pour afficher l’image au moyen d’un navigateur internet.
  7. 7. Procédé selon l’une quelconque des revendications précédentes, dans lequel le dispositif informatique (Ml, M2,..., Mn) produit un objet informatique dynamique, mémorisé dans une mémoire vive du dispositif, comprenant des conteneurs d’images incorporant uniquement la ou les images matricielles affichées sur l’écran.
  8. 8. Procédé selon l’une quelconque des revendications précédentes, dans lequel les écrans (DISPLAY) des dispositifs informatiques (Ml, M2, Mn) comprennent chacun une matrice d’au moins de L x H pixels d’affichage : dans lequel le dispositif formant serveur (MO) : - mémorise les paramètres LetH ; - découpe le plan numérique (PLAN) en une série d’images matricielles (SUBPLAN1, SUBPLAN2,..., SUBPLANQ) de dimensions inférieures ou égales à L x H pixels si le plan numérique (PLAN) comporte Lp x Hp pixels avec Lp > L et/ou Hp > H, et produit un fichier intermédiaire pour chaque image matricielle de ladite série ; et dans lequel le dispositif informatique (Ml, M2,..., Mn) met à jour ou crée le fichier de visualisation en fonction de la série d’images (SUB PLAN1, SUBPLAN2,..., SUB PLANQ) contenue dans les fichiers intermédiaires.
  9. 9. Procédé selon la revendication 8, dans lequel la matrice de L x H pixels correspond à l’écran de plus petite taille parmi les écrans (DISPLAY) des dispositifs informatiques (Ml, M2,..Mn).
  10. 10. Système informatique de visualisation d’un plan numérique (PLAN), comprenant des dispositifs informatiques (Ml, M2,...Mn), connectés au travers d’un réseau informatique (RI) à un dispositif informatique formant serveur (MO), chaque dispositif informatique (Ml, M2,...Mn) comprenant une mémoire informatique pour mémoriser au moins un fichier informatique (DOC RECOMP), dit « de visualisation», comprenant au moins une image matricielle (SUB_PLAN1, SUBPLAN2,..., SUB_PLANQ), des données (NOM_PLAN) d’identification, et des données de version (DATE), un écran (DISPLAY) et une unité de traitement pour piloter l’écran de manière à afficher l’image matricielle du fichier de visualisation mémorisé dans ladite mémoire, le dispositif informatique formant serveur (MO) étant configuré pour : - la réception d’un fichier informatique (DOCPDF), dit « de source », codant le plan numérique (PLAN) ; - la production, en fonction du fichier source (DOC PDF), d’au moins un fichier informatique (DOC_PNGl, DOCPNG2, ..., DOCPNGQ), dit «intermédiaire», comprenant une image matricielle (SUBPLAN1, SUB PLAN2,..., SUB_PLANQ) d’au moins une partie du plan numérique (PLAN), des données (NOM_PLAN) d’identification et de version associées au plan numérique (PLAN), et des données (RES) de résolution de l’image matricielle ; l’envoi de chaque fichier intermédiaire aux dispositifs informatiques ; et chaque dispositif informatique (Ml, M2, ..., Mn) étant configuré pour : la réception et l’enregistrement de chaque fichier intermédiaire (DOC_PNGl, DOC PNG2, ..., DOC PNGQ) envoyé par le dispositif formant serveur (MO); et l’affichage sur l’écran (DISPLAY) du plan numérique (PLAN) en fonction du ou des images matricielles (SUB_PLAN1, SUBPL AN2,..., SUB_PLANQ) du ou des fichiers intermédiaires ayant les données d’identification (NOM PLAN) associées au plan numérique (PLAN) et les données de version (DATE) les plus récentes.
  11. 11. Système selon la revendication 10, apte à mettre en œuvre un procédé selon Tune quelconque des revendications 2 à 9.
FR1561026A 2015-11-17 2015-11-17 Procede de visualisation d'un plan par des dispositifs informatiques Active FR3043806B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1561026A FR3043806B1 (fr) 2015-11-17 2015-11-17 Procede de visualisation d'un plan par des dispositifs informatiques

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1561026A FR3043806B1 (fr) 2015-11-17 2015-11-17 Procede de visualisation d'un plan par des dispositifs informatiques
FR1561026 2015-11-17

Publications (2)

Publication Number Publication Date
FR3043806A1 true FR3043806A1 (fr) 2017-05-19
FR3043806B1 FR3043806B1 (fr) 2018-10-05

Family

ID=55646700

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1561026A Active FR3043806B1 (fr) 2015-11-17 2015-11-17 Procede de visualisation d'un plan par des dispositifs informatiques

Country Status (1)

Country Link
FR (1) FR3043806B1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3077662A1 (fr) * 2018-02-02 2019-08-09 Bluepad Procede de traitement d’une vue d’un plan numerique
FR3083347A1 (fr) 2018-06-27 2020-01-03 Bluepad Procede de selection d un point d un plan ou d une carte affiche sur un dispositif d affichage tactile et dispositif d affichage tactile
FR3095060A1 (fr) 2019-04-10 2020-10-16 Bluepad Procédé d’échange de données à travers un réseau intermittent et système mettant en œuvre le procédé

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070046698A1 (en) * 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
US20080162635A1 (en) * 2007-01-03 2008-07-03 Interwise Ltd. Method and apparatus for participating in a conference session over a data communication network
US20100316302A1 (en) * 2005-09-22 2010-12-16 Google, Inc., A Delaware Corporation Adaptive Image Maps
US20120005301A1 (en) * 2010-06-30 2012-01-05 Skype Limited Sharing an image
US20140002504A1 (en) * 2012-06-28 2014-01-02 Microsoft Corporation Generation based update system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070046698A1 (en) * 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 (en) * 2005-09-22 2010-12-16 Google, Inc., A Delaware Corporation Adaptive Image Maps
US20080162635A1 (en) * 2007-01-03 2008-07-03 Interwise Ltd. Method and apparatus for participating in a conference session over a data communication network
US20120005301A1 (en) * 2010-06-30 2012-01-05 Skype Limited Sharing an image
US20140002504A1 (en) * 2012-06-28 2014-01-02 Microsoft Corporation Generation based update system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3077662A1 (fr) * 2018-02-02 2019-08-09 Bluepad Procede de traitement d’une vue d’un plan numerique
FR3083347A1 (fr) 2018-06-27 2020-01-03 Bluepad Procede de selection d un point d un plan ou d une carte affiche sur un dispositif d affichage tactile et dispositif d affichage tactile
FR3095060A1 (fr) 2019-04-10 2020-10-16 Bluepad Procédé d’échange de données à travers un réseau intermittent et système mettant en œuvre le procédé

Also Published As

Publication number Publication date
FR3043806B1 (fr) 2018-10-05

Similar Documents

Publication Publication Date Title
US11132377B2 (en) Server implemented geographic information system with graphical interface
AU2009286145B2 (en) Architectures and methods for creating and representing time-dependent imagery
CN105900121B (zh) 用于生成活动流的方法
US10922339B2 (en) Portable globe creation for a geographical information system
US20140372427A1 (en) Real-time analytic report analysis and retrieval framework
CN110489725B (zh) 三维可视化方法
WO2011106415A2 (fr) Création de globe portable pour un système d'informations géographiques
US11238632B2 (en) Interface to index and display geospatial data
KR102361112B1 (ko) 유사 그룹 요소 추출
FR3043806A1 (fr) Procede de visualisation d'un plan par des dispositifs informatiques
WO2009125115A2 (fr) Dispositif et procédé de gestion de l'accessibilité à des objets réels ou virtuels dans des lieux différents
CN110119386A (zh) 数据处理方法、数据处理装置、介质和计算设备
JP2015061167A5 (fr)
FR3077662A1 (fr) Procede de traitement d’une vue d’un plan numerique
CN112069274A (zh) 一种分布式影像切片处理方法
CN105808603A (zh) 图片管理的方法及装置
FR3048095A1 (fr) Procede de visualisation rapide d'un element de plan par des dispositifs informatiques en utilisant les rectangles a limite minimum
Bobowski Easy Recording System: Solutions based on web free apps databases
Yershov et al. Using concatenated steganography for visual analysis in GIS SOA
CN115242670A (zh) 一种网络资产信息融合方法、系统及计算机设备
CN117421285A (zh) 图片数据缓存方法和装置、计算机设备和存储介质
CN117171283A (zh) 地图服务的更新方法、系统和电子设备
FR2826213A1 (fr) Procede et systeme de diffusion d'images numeriques
WO2015177283A1 (fr) Procédé de personnalisation d'un objet personnalisable pour un système client/serveur; support d'enregistrement d'informations et système client/serveur associés

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20170519

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9