Brevet FR2826487A1 — publié le 20021227

PROCEDE ET SYSTEME D'INFORMATION CARTOGRAPHIQUE La présente invention concerne le domaine des systèmes d'information géographique, et plus particulièrement des systèmes comportant un serveur de données géographiques et des équipements mobiles raccordés par l'intermédiaire d'un réseau, par exemple téléphonique ou Internet. Le principe général de tels systèmes est connu. On connaît également des réalisations particulières, telle celle décrite dans le brevet PCT W001/28270. Ce brevet décrit un système comprenant des stations mobiles équipées chacune d'un moyen de localisation géographique. Les données graphiques sont fournies par un serveur par l'intermédiaire d'un réseau de communication, en fonction des informations de localisation acquises par l'équipement mobile. Les équipements mobiles comportent par ailleurs des moyens de stockage pour le stockage de données de base liées géographiques et des moyens pour l'affichage de données géographiques tels qu'une carte. Le brevet PCT WO101370 décrit un autre système de communications sans fil permettant de générer des informations cartographiques dans un service cartographique et de les transmettre à un client mobile. La carte est constituée graduellement sur une unité d'affichage en fonction de la position géographique du client et de son déplacement. Après un seul appel au serveur du service, une carte représentant tout un secteur géographique est transmise dans un flux de données sous la forme de petits segments de carte séparés. Le client décondense le flux de données en temps réel, procède à l'extraction des segments de carte et les affiche sur l'unité d'affichage au fur et à mesure qu'il les reçoit. La base de données cartographique trie les segments de carte selon un ordre spécifique basé sur l'ordre selon lequel les segments de carte doivent être affichés sur la fenêtre du client. Le tri repose sur : la position du client, le déplacement du client (la direction et la vitesse), et le temps (RTT) de transmission d'une carte. Ces différentes solutions sont figées, dans la mesure où l'équipement mobile est passif au regard des informations cartographiques délivrées par le serveur. Elles ne permettent pas de personnaliser les informations cartographiques visualisées sur l'équipement mobile en fonction d'un utilisateur ou d'une communauté d'utilisateurs. Tous les utilisateurs des systèmes d'informations de l'art antérieur recevront la même information géographique. Le but de la présente invention est de remédier à cet inconvénient en proposant une solution améliorée permettant de personnaliser les informations géographiques, tout en exploitant un serveur cartographique ou géographique unique et commun à tout les utilisateurs. A cet effet, l'invention concerne selon son acception la plus générale un système d'information cartographique constitué par au moins un serveur et une pluralité d'équipement de radiocommunication mobile, le serveur comportant une base de donnée cartographique pour l'enregistrement de l'ensemble des dalles vectorielles et une mémoire pour l'enregistrement de données d'information non cartographiques, les terminaux mobiles comportant une mémoire pour l'enregistrement d'un sous-ensemble de dalles vectorielles et des moyens de calcul pour le rendu et la manipulation de cartes géographiques, caractérisé en ce que le serveur comporte en outre des moyens pour recevoir et enregistrer des données d'informations géolocalisées transmises par un équipement de radiocommunication mobile, ledit équipement de radiocommunication mobile enregistrant les données d'informations géolocalisées en local. Avantageusement, la mémoire du serveur pour l'enregistrement des données d'information non cartographiques comporte l'identification de la communauté d'appartenance de l'équipement de radiocommunication ayant transmis la donnée d'information considérée. Selon une variante, les équipements de radiocommunication mobile comporte des moyens pour établir une session avec le serveur consistant à identifier l'équipement auprès du serveur, et des moyens pour transmettre au serveur un fichier comportant les données d'information non cartographiques, le serveur comportant des moyens pour intégrer dans la mémoire de données d'information non cartographiques lesdites informations provenant dudit terminal, associées à l'identifiant dudit terminal. Avantageusement, le serveur comporte des moyens pour sélectionner les données d'informations non cartographiques en fonction de l'appartenance de l'identifiant du terminal à une communauté de terminaux. L'invention concerne également un procédé de communication d'informations cartographiques et d'informations non cartographiques entre un serveur et des terminaux de radiocommunication caractérisé en ce qu'il comporte la transmission d'informations non cartographiques par un terminal au serveur et d'enregistrement sur le serveur desdites informations. Avantageusment, les données transmises par le terminal sont formées par un fichier comprenant un bloc contenant une entête déterminant la nature dudit fichier, un bloc d'offset contenant les coordonnées de référence. La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation. Le système selon l'exemple de réalisation décrit dans ce qui suit comporte tout d'abord un serveur géographique, comportant une base cartographiques dans laquelle les objets vectoriels ont été divisé en 3 classes : - Surfaces (Polygones) - Linéaires - Points Les Points, Linéaires et Surfaces sont pré-classés du plus important (vue de loin) au moins important (vue de près). De même pour les catégories d'icônes, la catégorie la plus importante doit apparaître en premier. Cela permet d'afficher en priorité les couches les plus importantes. De même on suppose que l'affichage des objets linéaires se fera toujours par-dessus tout objet surfacique. Les objets points eux s'afficheront par-dessus les linéaires. Enfin les icônes seront par-dessus tout le reste. Il est important également de pré-classer les objets de type surfaces par type (Mer sous Sol, Sol sous Foret, Foret sous Lac, etc.). Tout autre mélange d'ordre d'affichage ou cas particulier devra être géré par l'application elle-même. Les types des différentes classes ne sont pas toujours les mêmes (Par exemple, le type METRO sera utilisé uniquement dans la classe Point-Station-et Linéaire- Lignes.). Les coordonnées sont stockées en WGS84 absolu, sous forme d'entiers longs (WGS*10^6). D'autres systèmes de coordonnées sont néanmoins possibles. Tous les offsets présents dans le fichier sont relatifs au début du fichier, non compris l'entête PDB. Cette entête est conservée pour assurer la compatibilité Palm. Pour cette même raison, les données sont alignées sur des pages de 32Ko (Aucune donnée n'est à cheval sur deux pages). Toute donnée dont la taille est supérieure à 1 octet est stockée au format Motorola (little endian) [nom commercial] pour optimisation sur Palm [nom commercial]. Format du fichier Dans ce format de fichier, les blocs descriptifs s'enchaînent dans un ordre précis : 1. Entête PDB, 2. Entête IEVF puis 3. bloc d'Offsets. Les blocs suivants étant pointés à partir du bloc offset, leur ordre n'a pas d'importance. Il ne faut donc pas supposer un quelconque ordre d'enchaînement. L'encapsulation du fichier en PDB est nécessaire pour assurer la compatibilité avec le PALM [nom commercial]. Les autres plate-formes peuvent sauter cette entête étant donné qu'elle ne contient aucune information pertinente. Pour cela, lire l'entier long à l'offset 0x56 du fichier global (format Motorola [nom commercial]). Cette valeur représente l'offset sur le début des données IEVF, par rapport au début du fichier. Par la suite, tous les offsets auront comme base le début des données IEVF. L'entête IEVF est divisé en 2 parties : Une partie statique où chaque élément aura la même place d'un fichier à un autre, et une partie dynamique ou les données dépendent du contenu de la partie statique. Partie Taille Abrégé Donnée Statique Offset 0x0000 2 Marker Marquage : Pour l'instant ='IS'= 0x49 Ox53 0x0002'4CRCDouble CRC, 1 Word = CRC par Addition, 1 Word = CRC par Ou Exclusif OxOO06 4 Size Taille totale du fichier IEVF OxOOOA 2 staticsize Taille de l'entête statique OxOOOC 2 Headersize Taille de l'entête totale. OxOOOE 1 Types 5 bits : Type de carte (Ville, pays, salon, etc.) 3 bits : Type de coordonnées ( WGS84, Metrique, etc. ) OxOOOF 3 Creation Date de création : Date 1 byte : Année-2000 1 byte : Mois 1 byte : Jour 0x0012 2 Version Version du format : 1 byte : Version majeure 1 byte : Version mineure 0x0014 2 Flags Indicateurs divers : Bit 0 : Fichier crypté Bit 1 : Fichier découpé en page de 32Ko Bit 2-7 : à définir 0x0016 16 MapRect Coordonnées absolues du rectangle englobant de la carte : 1 long : X Minimum 1 long : Y Minimum 1 long : X Maximum 1 long : Y Maximum 0x0026 2 SfCount Nombre d'objets de classe Surface 0x0028 2 SfLyCount Nombre de couches (Layers) d'objet Surfaces Ox002A 2 LnCount Nombre d'objet de classe Linéaire Ox002C 2 LnLyCount Nombre de couche d'objets Linéaires Ox002E 2 PtCount Nombre d'objet de classe Point 0x0030 2 PtLyCount Nombre de couche d'objets Points 0x0032 2 CatIconCount Nombre de catégories d'icônes (Hôtels, restaurants, etc.) 0x0034 2 BmpCount Nombre de bitmap (Navigation + Catégorie d'icônes) 0x0036 2 NodeCount Nombre de noeuds (Itinéraires) 0x0038 2 ExtraCount Nombre d' extra info Ox003A 1 LangCount Nombre de langues supportées dans le fichier Taille totale de la pertie statique : 59 (0x3B) octets Partie dynamique : Multipli-Taille Donnée cateurs 2 Nombre d'objet dans ce Layer SfLyCount 2 Type Ismap du Layer 2 Nombre d'objet dans ce Layer LnLyCount 2 Type Ismap du Layer 2 Nombre d'objet dans ce Layer PtLyCount 2 Type Ismap du Layer 1 2 Nombre de mot du dictionnaire des adresses Icônes (IconZipCount) CatIcon 4 Catégorie d'icône (IDService) Count 2 Nombre d'icône de cette catégorie LangCount x Nom de la catégorie (Chaînes complètes) LangCount 3 Codes Internationaux des langues supportées (FRE = France) 2 Nombre de mots dans le dictionnaire des objets LangCount 2 Nombre de mots dans le dictionnaire des Icônes LangCount x Nom de la carte (Chaînes complètes) Chaînes Complètes : 1 byte : Longueur de la chaîne (non compris le zéro terminal) X byte : Caractères 1 byte : 0, zéro terminal La partie Entête se termine ici. Si le prochain octet n'est pas aligné sur 4, l'entête sera suivie d'autant d'octets vides que nécessaire pour s'aligner. La taille de l'entête prends en compte ces octets d'alignement, de façon à pouvoir sauter au bloc suivant. Bloc Offsets Le bloc offset permet de pointer n'importe quelle entité dans le fichier de façon directe. Etant lui-même dynamique, les applications devront calculer et conserver des références sur le début des offsets d'une entité particulière. Tous les offsets sont des entiers longs (4 Bytes) Multiplicateurs Donnée SfCount Offsets sur les objets Surfaces LnCount Offsets sur les objets Linéaires PtCount Offsets sur les objets Points LangCount Offset sur l'arbre lexicographique des objets vectoriels Offsets sur les X mots du dictionnaire des LangCount * X objets vectoriels Offsets sur les icônes. Attention IconCount n'est pas accessible directement dans IconCount l'entête, il faut le calculer en faisant la somme des icônes contenus dans chaque catégorie. LangCount Offset sur l'arbre lexicographique des icônes Offsets sur les X mots du dictionnaire des LangCount * X icônes icônes BmpCount Offsets sur les bitmaps NodeCount Offsets sur les noeuds ExtraCount Offsets sur les extra info Arbre de décompression Huffman pour l'arbre LangCount lexico. des objets vectoriels Arbre de décompression Huffman pour le LangCount dictionnaire des objets vectoriels Arbre de décompression Huffman pour l'arbre LangCount lexico. des icônes Arbre de décompression Huffman pour le LangCount dictionnaire des icônes Arbre de décompression Huffman pour les 1 adresses des icônes. Arbre de décompression Huffman pour les villes/CP des icônes. Offsets sur les mots du dictionnaire de villes/CP des icônes. (voir la partie IconZipCount dynamique de l'entête pour trouver IconZipCount) Tout offset ayant la valeur 0 signifie que l'élément n'est pas disponible dans le fichier. Dictionnaire de mots Le dictionnaire de mot est une suite de mot compressé à l'aide de la méthode Huffman. Bien qu'un encodage Huffman soit une série de bit, chaque mot est aligné sur un octet plein. Le dictionnaire peut se répartir sur plusieurs pages de 32K, mais un mot ne débordera jamais d'une page. Arbre lexicographique L'arbre lexicographique sert à effectuer des recherches sur les PDAs. Sa structure est relativement complexe, et son utilité reste confiné au PDAs pour l'instant. Sa description détaillée sera donc faite ultérieurement. Bitmaps Les bitmaps servent à stocker les différents bitmaps de navigation utilisés sur PALM et PocketPC ainsi que les images des catégories d'icônes. Structure : Offset Taille Abrégé Donnée 0x0000 1 Type Type du bitmap : 0 = Pas de type (utilisé pour les icônes) 1 = Zoom In 2 = Zoom Out 3 = Arrow Up 4 = Arrow Down 5 = Arrow Left 6 = Arrow Right 7 = Back 8 = Small Ismap Logo 9 = Pin 10 = Metro Station 0xOO01 1 ColorMask Masque de disponibilité du bitmap dans diverses profondeurs : Bit 0 : 2 Couleurs (Inutilisé) Bit 1 : 4 Couleurs Bit 2 : 16 Couleurs (Inutilisé) Bit 3 : 256 Couleurs Bit 4-7 : Inutilisés OxOO02 2 Width Largeur du bitmap OxOO04 2 Height Hauteur du bitmap 0x0006 X4 Bitmap4 Données du bitmap en 4 couleurs. Chaque point est codé sur 2 bits (4 pixels/octets). Chaque ligne est alignée sur un octet plein (les pixels inutilisés en fin de lignes sont à 0). X4 vaut : Height * ( (Width+3) and OxFFFC) 0x0006 X256 Bitmap256 Données du bitmap en 256 couleurs. + Chaque point est codé sur un octet. X4 Les bitmap 256 sont codés sous formes de sprites pour une économie de place et un gain de vitesse à l'affichage. Pour chaque ligne horizontale : 1 byte : Nombre d'opérations horizontales Pour chaque opération : 1 byte : Offset/au X gauche du bitmap. 1 byte : Nombre de pixel à copier X byte : Pixels a. Objets vectoriels Les objets vectoriels (et les icônes) ont une sousstructure commune pour gérer les noms dans différentes langues. Cette structure sera référencée sous le nom de chaîne multi-langue : Multipli- Taille Abrégé Donnée cateurs 1/0 LLgCount Nombre de langues disponibles 1 pour cette chaîne. Présent si et seulement si LangCount > l, sinon assumé à 1 1/0 Index Index de la langue dans la liste des langues supportées par le fichier. LlgCount Présent si et seulement si LangCount > l. 1 wordcount Nombre de mots composant la chaîne. 0 si vide. WordCount 2 WordIndex Index du mot dans le dictionnaire approprié Objets Points : Taille Abrégé Donnée 1 Info Information de taille des coordonnées et présence d'une extra info. Bit 0-2 : Taille en octet des coordonnées (CoSize) Bit 7 : Presence d'une extra-info (HasExtra) 2/0 ExtraInfo Index d'une extra-info, si HasExtra est présent CoSize Coordonnée X absolue du pointCoordonnée XMin de la carte CoSize y Coordonnée Y absolue du pointCoordonnée YMin de la carte X Name Nom de l'objet (chaîne multi-langue) Objets Linéaires : Multipli- Taille Abrégé Donnée cateurs 1 Infol Taille des coordonnées et présence d'une extra-info. Bit 0-1 : Taille en octet des XMin, Xmax,-1. (LP) Bit 2-3 : Taille en octet des largeur et hauteur,-1. (LS) 1 Bit 4 : Circulation autorisée du debut vers la fin. Bit 5 : Circulation autorisée de la fin vers le debut. Bit 6 : Inutilisé Bit 7 : Presence d'une extrainfo (HasExtra) 2*LP XMin Coordonnées top-left du YMin rectangle englobant l'objet, 1 relatives au top-left du rectangle englobant la carte. 2*LS Width Largeur et hauteur du rectangle 1 Height englobant l'objet. 2 / 0 ExtraInfo Index d'une extra-info, si 1 HasExtra est présent 1 Info2 Taille des coordonnées et multi-morceau. Bit 0-2 : Taille du premier 1 point d'un morceau. (MP) Bit 3-5 : Taille des points suivants d'un morceau. (MN) Bit 7 : Multi-morceaux (Multi) 2/0 PcCount Nombre de morceau de l'objet, 1 si Multi est présent, sinon assumé à 1 1 Thickness Epaisseur de l'objet sur une 1 échelle de 0 (très fin) à 80 (très épais) 2 PtCount Bit 0-14 : Nombre de point du morceau PcCount Bit 15 : Changement de sens de circulation. (CSC) 1 ExtraDir Si CSC, nouvelles données de circulation : Bit 0 : Circulation autorisée du début vers la fin. Bit 1 : Circulation autorisée de la fin vers le début. 2*MP Xl Coordonnées du premier point du Yl morceau, relative au top-left du rectangle englobant de l'objet. 2*MP* Xn Coordonnées des points PtCount Yn suivants, chacune étant - 1 relative au point précédent. X Name Nom de l'objet (chaîne multilangue) Objets Surfaces : Multipli- Abrég Donnée Taille cateurs é 1 Infol Taille des coordonnées et présence d'une extra-info. Bit 0-2 : Taille en octet des XMin, XMax. (LP) Bit 3-5 : Taille en octet des Largeur et Hauteur. (LS) Bit 7 : Presence d'une extrainfo (HasExtra) 2*LP XMin Coordonnées top-left du YMin rectangle englobant l'objet, relatives au top-left du rectangle englobant la carte. 2*LS Width Largeur et hauteur du rectangle Height englobant l'objet. 2/0 Extrain Index d'une extra-info, si HasExtra est présent 1 Info2 Taille des coordonnées et multimorceau. Bit 0-2 : Taille du premier 1 point d'un morceau. (MP) Bit 3-5 : Taille des points suivants d'un morceau. (MN) Bit 7 : Multi-morceaux (Multi) 2/0 PcCount Nombre de morceau de l'objet, si 1 Multi est présent, sinon assumé à 1 1 PtCount Nombre de point du morceau. Les morceaux de surface ne doivent pas contenir plus de 100 points. Si c'est le cas, le morceau est découpé en morceaux plus petits, de 100 points maximum. PcCount 2*MP X1 Coordonnées du premier point du Y1 morceau, relative au top-left du rectangle englobant de l'objet. 2*MP* Xn Coordonnées des points suivants, PtCount Yn chacune étant relative au point - 1 précédent. X Name Nom de l'objet (chaîne multilangue) b. Arbres Huffman c. Les arbres Huffman ne sont pas stockés sous forme d'arbre, mais sous la forme d'une structure qui permet de reconstruire l'arbre véritable. Multipli-Taille Abrégé Donnée cateurs 1 1 Count Nombre d'élément de l'arbre 1 Data Donnée de la feuille Count 1 Weight Poids de la feuille d. Icônes Les Villes/CPs sont encodés avec un Arbre Huffman spécial, unique pour toutes les langues, et placé dans un dictionnaire unique également. Les différentes informations des Adresses sont aussi encodées avec un Arbre unique, indépendant de la langue. Structure : Taille Abrégé Donnée 1 Info Numéro de BMP associé et taille des coordonnées. Bit 0-11 : NO de BMP Bit 12 : Présence d'une extra info (HasExtra) Bit 13-15 : Taille des coordonnées (CS) 2 ExtraIn Index d'une extra-info, si HasExtra est fo présent 2*CS X Coordonnées X, Y de l'icône, relatives au y top-left du rectangle englobant la carte. X Name Nom de l'objet (Chaîne complète) 1 Flags Flag de présence des diverses informations de l'icône. Bit 0 : de Rue Bit 1 Zip Code Bit 2 Nom de la Ville Bit 3 : Adresse Bit 4 : de Téléphone Bit 5 : de Fax Bit 6 E-Mail Bit 7 URL du Site Web 0/1/RoadN Si Flags. BitO, NO de rue codé sur 1 ou 2 2 octet. Si RoadN il est codé sur 1 octet, sinon les 7 bit de poids faible sont sur le premier octet avec le Bit 7 à 1, le reste étant sur un second octet. 0/1/ZipCode Si Flags. Bitl, Index du ZipCode dans le 2 dictionnaire des Villes/CPs. Codé sur 1 ou 2 octet comme RoadN. 0/1/City Si Flags. Bit2, Index du nom de ville dans 2 le dictionnaire des Villes/CPs. Codé sur 1 ou 2 octets comme RoadN Address Adresse codé Huffman avec l'Arbre des adresse Icônes. X TelNum NO de Téléphone codé Huffman avec l'Arbre des adresse Icônes. X FaxNum NO de Fax codé Huffman avec l'Arbre des adresse Icônes. X Email Adresse EMail codé Huffman avec l'Arbre des adresse Icônes. X URL URL (sans le http :// ) codé Huffman avec l'Arbre des adresse Icônes. e. Noeuds f. Extra infos Les extra infos sont organisée en chunks . Chaque chunck est marqué d'un type et d'une taille. Ceci permet à l'application de traiter le chunk en cours, ou de l'ignorer et de sauter directement au suivant en ignorant son contenu. Structure : Taille Abrégé Donnée 1 Type Type du chunk, 0 pour indiquer la fin de la chaîne. 1/2 Taille Taille du chunk. Si Taille il est codé sur 1 octet, sinon les 7 bit de poids faible sont sur le premier octet avec le Bit 7 à 1, le reste étant sur un second octet X Data Donnée du chunk, à interpréter par l'application en fonction de son type. Il n'y a pas de type défini pour l'instant. A voir en fonction des besoins. Chaque valeur de type définie devra le rester à vie, pour éviter toute erreur d'interprétation entre anciennes et nouvelles versions des cartes ou des applications. Calcul des CRCs Les CRCs sont codé chacun sur 2 octets, format Motorola. Le premier Word représente la somme de tous les Words du fichier IEVF (Non comprise l'entête PDB). Si la taille du fichier est impaire, le dernier octet n'est pas pris en compte. Le second Word représente le Ou Exclusif de tous les Words du fichiers IEVF, sur lequel est appliqué le premier Word en Ou Exclusif également. Ceci rend les deux calculs indépendants, mais les deux CRCs solidaires. Là encore, si la taille du fichier est impaire, le dernier octet n'est pas pris en compte. Attention : Lors de la vérification des CRCs, les emplacement des CRCs doivent êtres à 0 ! Type de carte et de coordonnées L'octet Type de l'entête est composé de la manière suivant : 5 bits : Type de carte (Ville, pays, salon, etc.) 3 bits : Type de coordonnée (WGS84, Métrique, etc.) Les valeurs du type de carte sont : 0 : Dalle 1 : Pays 2 : Région 3 : Ville 4 : Salon (Intra-batiment) Il reste 27 valeurs non définies. Les valeurs du type de coordonnée sont : 0 : WGS84 * 1O^6 Il reste 7 valeurs non définies. REVENDICATIONS 1-Système d'information cartographique constitué par au moins un serveur et une pluralité d'équipement de radiocommunication mobile, le serveur comportant une base de donnée cartographique pour l'enregistrement de l'ensemble des dalles vectorielles et une mémoire pour l'enregistrement de données d'information non cartographiques, les terminaux mobiles comportant une mémoire pour l'enregistrement d'un sous-ensemble de dalles vectorielles et des moyens de calcul pour le rendu et la manipulation de cartes géographiques, caractérisé en ce que le serveur comporte en outre des moyens pour recevoir et enregistrer des données d'informations géolocalisées transmises par un équipement de radiocommunication mobile, ledit équipement de radiocommunication mobile enregistrant les données d'informations géolocalisées en local. 2-Système d'information cartographique selon la revendication 1 caractérisé en ce que la mémoire du serveur pour l'enregistrement des données d'information non cartographiques comporte l'identification de la communauté d'appartenance de l'équipement de radiocommunication ayant transmis la donnée d'information considérée. 3-Système d'information cartographique selon la revendication 2 caractérisé en ce que les équipements de radiocommunication mobile comporte des moyens pour établir une session avec le serveur consistant à identifier l'équipement auprès du serveur, et des moyens pour transmettre au serveur un fichier comportant les données d'information non cartographiques, le serveur comportant des moyens pour intégrer dans la mémoire de données d'information non cartographiques lesdites informations provenant dudit terminal, associées à l'identifiant dudit terminal. 4 - Système d'information cartographique selon la revendication 2 ou 3 caractérisé en ce que le serveur comporte des moyens pour sélectionner les données d'informations non cartographiques en fonction de l'appartenance de l'identifiant du terminal à une communauté de terminaux. 5-Procédé de communication d'informations cartographiques et d'informations non cartographiques entre un serveur et des terminaux de radiocommunication caractérisé en ce qu'il comporte la transmission d'informations non cartographiques par un terminal au serveur et d'enregistrement sur le serveur desdites informations. 6-Procédé de communication selon la revendication 5 caractérisé en ce que les données transmises par le terminal sont formées par un fichier comprenant un bloc contenant une entête déterminant la nature dudit fichier, et au moins un bloc d'offset contenant les coordonnées de référence. 7-Procédé de communication selon la revendication 5 ou 6 caractérisé en ce que les données transmises sont organisées pour présenter un premier bloc Entête PDB, un deuxième bloc Entête IEVF puis au moins un bloc d'Offset, les blocs suivants étant pointés à partir du bloc offset. 8-Procédé de communication selon la revendication 7 caractérisé en ce que le bloc d'en tête IEVF comporte une partie statique où chaque élément aura la même place d'un fichier à un autre, et une partie dynamique où les données dépendent du contenu de la partie statique. 9-Procédé de communication selon l'une quelconque des revendications précédentes 5 à 8 caractérisé en ce que le bloc offset comprend au moins un arbre de décompression Huffman pour le dictionnaire des objets vectoriels ou le dictionnaire des icônes ou le dictionnaire des villes ou des mots clés. 10-Procédé de communication selon la revendication 9 caractérisé en ce que l'arbre de décompression Huffman sont stockés sous forme d'une structure de reconstruction de l'arbre. 11-Procédé de communication selon l'une quelconque des revendications 5 à 10 caractérisé en ce que les objets vectoriels ont été divisé en 3 classes, polygones, linéaires et points. 12-Procédé de communication selon la revendication 11 caractérisé en ce que les Points, Linéaires et Surfaces sont pré-classés du plus important (vue de loin) au moins important (vue de près). 13-Procédé de communication selon la revendication 11 caractérisé en ce que les catégories d'icônes la catégorie la plus importante doit apparaître en premier. 14-Procédé de communication selon la revendication 11 caractérisé en ce que l'affichage des objets linéaires se fait toujours par-dessus tout objet surfacique et en ce que les objets points eux s'afficheront par-dessus les linéaires, les icônes étant affichées par-dessus tout le reste. 15-Procédé de communication selon la revendication 11 caractérisé en ce que les objets de type surfaces sont classés par type (Mer sous Sol, Sol sous Foret, Foret sous Lac, etc.).