Etude exploratoire XML / SVG IDL_CERTU1/ETU_001 / 1.1 - Lara

Edité le 11 juin 2002 Etude exploratoire XML / SVG CERTU7. VOLUMETRIE ET SOLUTIONSLa gestion de gros volumes de données constitue la principale limite du SVG. Des tests de volumétrie exposésdans le chapitre 7.1.2 permettent de quantifier cette limite. Les solutions existantes pour la gestion de grosvolumes de données cartographiques sont présentées ensuite, afin d’étudier dans quelle mesure elles peuventêtre mises en œuvre avec SVG.7.1 VOLUMETRIE DES DONNEES7.1.1 GénéralitésNous avons vu qu’un des principaux problèmes de SVG est l’impossibilité de contrôler le volume desdonnées à télécharger. Voici quelques considérations permettant de limiter la taille des fichiers SVG.Un point intéressant des spécifications de SVG est que les outils traitant ce format doivent être capablesde lire les fichiers SVG compressés au format ZIP. Cela permet de réduire le fichier à moins du tiers de sa tailleoriginale, ce qui représente un gain très important.Ensuite, on peut essayer de réduire le contenu du fichier lui-même. Dans notre document SVG de lacarte du P.O.S., ce sont les coordonnées des points qui constituent la plus grande partie du fichier. On peutfacilement réduire la longueur de celles-ci au prix d’une perte de précision. Suivant l’utilisation que l’onsouhaite faire des données, cette perte peut être gênante ou non.L’utilisation d’une feuille de style CSS séparée, comme nous l’avons fait, évite de répéter pour chaqueobjet la définition de tout son style. Là encore, on réalise une économie de place non négligeable.7.1.2 Tests de volumétrieAfin de tester les limites de l’utilisation de SVG en termes de volumétrie des données, nous avonsessayé d’effectuer la conversion d’un fichier cadastral d’une grande communauté de communes depuis MapInfo.Le fichier original (.MAP) a une taille de 36.1 Mo. La conversion avec SVGMapMaker a échoué. On peut doncdéjà conclure que cet utilitaire n’est pas parfaitement fiable. Toutefois, les différents autres tests que nous avonseffectués nous permettent de dire que le fichier final aurait du avoir une taille comprise entre 50 et 60 Mo, pourun temps de conversion d’environ 3h sur un Pentium II 266 MHz.Avant d’échouer, l’utilitaire a tout de même produit un fichier de 5.3 Mo. Nous avons donc réalisé lesautres tests sur celui-ci. Une fois compressé, celui-ci n’occupe déjà plus que 953 ko. Pour ouvrir ce fichier avecAdobe SVG Viewer et Internet Explorer, il faut un temps de 1mn 30s avec un Pentium II 266 MHz. La mémoirevive occupée est de 70 Mo. Pour chaque opération de zoom, il faut ensuite compter environ 30s.La conclusion de ces tests est que si SVG est bien adapté pour les petits documents (notre exemple decarte de P.O.S. a une taille de 100 ko non compressée), il devient inutilisable pour les trop gros volumes.Malheureusement, lorsque l’on veut inclure le cadastre d’une commune ou une couche raster en fond, la tailledes fichiers nécessaires augmente très rapidement. La seule solution est alors de mettre en œuvre unearchitecture client-serveur plus complexe, dans laquelle seule la partie visible et ses alentours sont transférés auclient à chaque requête.SWORD - Nos réf. : IDL_CERTU1/ETU_001 / 1.1 Diffusion : contrôlée Page : 74/81