HTML5 et le webSIG : il n'y a pas que Canvas!
Par René-Luc D'Hont le vendredi 30 septembre 2011, 15:16 - Système d'Information Géographique (SIG) - Lien permanent
Cet article est inspiré par les réactions suite au FOSS4G 2011 et aux présentations de GIS cloud.
Qu'est ce que Canvas
Canvas est un nouvel élément HTML, définit dans la futur norme HTML5, permettant de dessiner de façon programmatique. Avec Canvas plus besoin de demander au serveur une image en fonction de paramètres, cette opération peut-être faite dans la page par le navigateur. Cela permet de réduire les interactions avec le serveur mais aussi d'alléger les échanges, un fichier texte peut-être compressé alors qu'une image non.
Certains avantages se trouvaient déjà dans le SVG. Avec le SVG il était possible de dessiner de façon programmatique, de faire des modifications dans la page Web, de compresser les données (le fichier SVG), d'afficher du HTML dans du SVG via foreignObject, etc. Mais son implémentation n'a jamais été mise en avant par les éditeurs, son API est assez lourde, et en tant que format XML c'est assez verbeux.
Il est vrai que Canvas propose une API simple, la possibilité de manipuler directement l'image et un affichage qui ne dépend que de l'exécution du JavaScript. Par contre si vous souhaitez mettre à jour les données affichées dans le Canvas il vous faudra tout redessiner.
Canvas est l'arbre qui cache la forêt du HTML5, et n'est pas en soi l'avenir du web SIG.
Les exemples de GIS cloud sont intéressant et performant, mais la solution de GIS cloud repose principalement sur un traitement côté serveur pour que les données soient optimisées pour la page Web. En fait les serveurs de GIS cloud envois à la page Web des données vectorielles simplifiés au format JSON et optimiser pour que le dessin dans Canvas soit rapide. De telles données pourraient être utiliser pour générer du SVG ou du VML, ou encore que le serveur envois ces données au format SVG et VML.
Alors oui GIS cloud starts HTML5 mapping revolution, car Canvas permet de repenser la communication entre serveur et client, mais vivement que d'autres choses comme :
- SVG-As-Image, afficher du SVG avec un élément img
- WebWorkers, faire des traitements dans un processus parallèle
- IndexedDB, enregistrer de l'information en mode déconnecté
- WebGL, utiliser la carte graphique
- HTML5 parser, ne plus utiliser de namespace
- etc
soient accessibles et utilisés par d'autres projets.
SVG-As-Image et WebGL des pistes à explorer
SVG-As-Image est la possibilité d'utiliser un fichier SVG comme source pour l'élément HTML img et/ou pour la propriété CSS background-image. L'intérêt de cette fonctionnalité est de diffuser des images au format vectoriel, ainsi de pourvoir compresser ces images et donc d'alléger les flux images. Dans le domaine des SIG pour que ceci soit intéressant, il faut pouvoir générer des fichiers SVG simplifier. On peut donc envisager 2 pistes :
- Comme GIS cloud, générer côté serveur une version simplifier des données puis créer le fichier SVG correspondant.
- Utiliser les WebWorkers pour simplifier et créer le contenu SVG
WebGL est la possibilité d'exploiter les capacité des carte graphiques directement dans une page web. Les démonstrations utilisent principalement la capacité d'affichage 3D comme par exemple WebGL Earth. Mais puisque cette technologie permet d'exploiter la carte graphique, on pourrait envisager de construire un système d'affichage cartographique 2D n'exploitant que WebGL.
Perspective ?
Les différentes normes autour de HTML5 et HTML5 ne sont pas encore finalisées. Les navigateurs évoluent vite et intègrent progressivement ces changements. Les habitudes de consommations du Web changent aussi très vite. Nous sommes donc à un moment charnière qui pourrait voir des projets intéressant émerger tout en espérant que certains éditeurs par leur position n'empêche pas cette éclosion.