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 WO01/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 1 ' 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 à tous 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.
Avantageusement, les données transmises par le terminal sont formées par un fichier comprenant un bloc contenant une en-tê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 cartographique dans laquelle les objets vectoriels ont été divisés 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 Forêt, Forêt 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'en-tête PDB. Cet en-tê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. En-tête PDB,
2. En-tê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 plates-formes peuvent sauter cet en-tê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'en-tê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 où les données dépendent du contenu de la partie statique.
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 En-tête se termine ici. Si le prochain octet n'est pas aligné sur 4, l' en-tête sera suivi d'autant d'octets vides que nécessaire pour s'aligner.
La taille de l'en-tête prend 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)
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ée 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
a. Objets vectoriels
Les objets vectoriels (et les icônes) ont une sous- structure 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 » :
Objets Points
Objets Linéaires
b. Arbres Huffman
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.
c. 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 encodees avec un Arbre unique, indépendant de la langue. Structure :
d. Nœuds e. Extra infos
Les extra infos sont organisée en « chunks » . Chaque « chunk » 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 :
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'en-tê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'en-tê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-bâti ent) II reste 27 valeurs non définies.
Les valeurs du type de coordonnée sont : 0 : WGS84 * 10Λ6 Il reste 7 valeurs non définies.