Paris Web 2012 : La cartographie en ligne d’hier à demain

Posté le 30 novembre 2012 dans Développement web | Google | Technologie | User experience , par Benjamin - 1 Commentaire
a-la-une

Sébastien a fait un bilan général de ce que nous avons suivi à Paris Web 2012, ainsi qu’une présentation de l’intérêt des profils atypiques dans les métiers du web d’aujourd’hui. À mon tour de revenir sur le sujet de l’une de conférence de cette année : Les nouveaux horizons de la cartographie sur le web par Benjamin Becquet.

Ça ne fait aucun doute aujourd’hui, lorsqu’on parle de cartographie grand public sur le web, l’acteur majoritaire et incontournable c’est Google Maps. Encore que depuis cette année, avec le passage de Foursquare à OpenStreetMap et l’arrivée de Apple Maps, cette domination est petit à petit remise en question.

Hier

Jusqu’au début des années 2000, les quelques solutions de cartographie se limitent à des cartes avec des niveaux de zoom très limités.
Le rendu visuels plutôt proche de plans papiers simplement numérisés, et la navigation au sein d’une carte se fait par décalage horizontal ou vertical de dimension prédéfinie.

Le rendu et l’interactivité sont gérés avec Flash ou du Java. Les rares à ne pas utiliser de plugin nécessitent un rechargement entier de la page pour changer de zone visualisée.
Ces systèmes sont propriétaires et ne n’offrent pas de solution d’intégration de carte sur un site tiers.

Aujourd’hui

Les apports de Google

Un nombre important de niveaux de zoom, le déplacement fluide avec affichage quasi-instantané, l’intégration simple de carte sur site, autant de fonctionnalités introduites par Google Maps, dont on ne pourrait plus se passer aujourd’hui.

Google n’est pas la première solution grand public, mais elle a su s’imposer comme un standard. Son fonctionnement « tout en un » a réuni un ensemble de critères pour en faire un (le ?) standard en terme de rendu et d’interactivité de carte.

Sans entrer dans les détails, rendre une zone géographique donnée nécessite un empilement de technologies différentes :

  • Les données (stockage, traitement, sélection)
  • Rendu des données tuiles (images à assembler, pour chaque niveau de zoom)
  • Hébergement de tuiles
  • Affichage de tuiles à la demande

Google Maps fournit l’ensemble de cet empilement sous forme d’un service principal, monolithique : Maps Javascript API.

D’autres services sont proposés via des API associables ou non à cette première :

  • Géocoding API : Conversion coordonnées/adresse postale
  • Directions API : Calcul d’itinéraire
  • Places API : Accès aux informations sur les services et établissements à proximité
  • Élévation API : Donnée d’élévation / altitude

La nécessaire alternative

On entend depuis quelques temps beaucoup parler d’OpenStreetMap. Rétrospectivement plus ancien que Google Maps, ce n’est qu’aujourd’hui qu’OSM parvient sur le devant de la scène. Notamment grâce à la volonté d’un certain nombre d’utilisateurs historiques de ne plus subir l’hégémonie du moteur de recherche.

D’une part, l’utilisation « de base » du service de Google est bien gratuite, mais les conditions générales d’utilisation limitent grandement les possibilités, et surtout l’usage un peu plus poussé nécessite une licence « Business » et donc engendre un coût non négligeable.

D’autre part, le géant sait investir là où il voit de l’intérêt, et ne se préoccupe que peu de l’intérêt public :

Pyongyang vu par Google Maps

Pyongyang vu par Google Maps

Pyongyang vu par OSM

Pyongyang vu par OSM

Les alternatives existent et sont aujourd’hui accessibles.

Source de données

OpenStreetMap n’est pas un équivalent de Google Maps. OpenStreetMap est uniquement une source de données, telle que présenté dans le modèle un peu plus haut, contribuable, duplicable et exploitable par tous (licence ODbL).
Indépendamment, OSM héberge également des tuiles.

Création des tuiles

Si on souhaite personnaliser ses tuiles (couleur des éléments, ne pas affiche les routes, afficher les forêts en bleu) il est possible de les générer et les héberger soi-même grâce à des outils comme Mapnik, ou faire appel à des société qui proposent, à des coûts différents, de générer et héberger des tuiles personnalisées.

Affichage et intéraction

Pour ensuite afficher ces tuiles il existes plusieurs librairies, offrant plus ou moins de fonctionnalités : OpenLayer, Leaflet, ModestMap,…

Les limites de l’utilisation de tuiles

Toutes ces solutions reposent toujours sur l’utilisation de tuiles. Il faut les générer (nécessite des ressources serveurs), les héberger (du stockage), les servir (de la bande passante). Cela implique également comme contrainte, pour limiter ces différentes charges serveur, de prédéfinir les niveaux de zoom disponibles, ainsi que le style de rendu de la carte (couleurs, éléments affichés, styles…).

À l’heure de Canvas et de WebGL, on peut envisager de ne plus transférer des tuiles statiques et lourdes, mais d’aller vers le vectoriel.

Demain

Ce qu’il manque aujourd’hui à la cartographie en ligne : plus de liberté de rendu, de l’interactivité poussée,… autant de possibilités limités par le principe des tuiles, multitude d’image bitmap.

Le vectoriel

Pour représenter des éléments graphiques, quel que soit le niveau de zoom, avec le même niveau de qualité visuelle, il est logiquement de s’orienter vers le vectoriel.

Avec des tuiles, représenter une ligne droite nécessite autant de pixels que cette ligne est longue et large, multiplié par le nombre de niveaux de zoom auxquels celle-ci doit être affichée. Bref, c’est lourd…

En vectoriel, représenter cette ligne nécessite deux points. Quel que soit le niveau de zoom. Côté interactivité, chaque élément pourra avoir son propre comportement. Par exemple le survol d’une route pourra mettre cette route en surbrillance sur tout son tracé, ou encore le résultat d’une recherche pourra être mis en avant en baissant l’opacité de tous les éléments ne correspondant pas aux critères. Le tout, sans nécessiter de quelconque rechargement ou transfert de données.

SVG, puis Canvas & WebGL

Le vectoriel permet donc de transférer infiniment moins de données. Et du côté du stockage, le format reste très proche des informations stockées en base de données, leur traitement est donc relativement léger. Les afficher par contre nécessite la mise en œuvre d’une solution de rendu.

La plus simple, et à première vue la plus évidente est le SVG. Mais afficher un grand nombre d’éléments (tels que ceux constituant une carte complexe) peut être extrêmement lourd pour un navigateur web.

Avec HTML5, Canvas et le WebGL se sont répandus, et offrent une autre possibilité : traiter des données vectorielles mais afficher des données bitmap. Il n’est ainsi pas nécessaire de stocker le volume considérable d’image, car celle-ci sont générées à la volée, grâce à Canvas. WebGL lorsque disponible, va permettre de profiter de l’accélération matérielle.
Le traitement des données et leur affichage sont donc déportés sur le client, le navigateur web, de la manière la plus fluide possible.

Google de ce côté a déjà une longueur d’avance :

Activer Google MapsGL

Activer Google MapsGL

Le Canvas de Google MapsGL

Le Canvas de Google MapsGL

Mais cette méthode peut, du moins pourra être utilisée indépendamment de Google. OpenLayers et Leaflet se penchent déjà dessus pour la partie ‘rendu’. Mais il faut encore mettre en place les techniques pour servir les données à afficher. Le GeoJSON est censé être là pour ça. Mais de l’avis de Benjamin Becquet, le GeoJSON est trop verbeux, il inclue trop d’informations non essentielles à l’affichage et alourdit donc inutilement les traitements.

Il y a encore des progrès, des avancées à faire de ce côté. Le rendu vectoriel d’information géographique est sans nul doute la solution qui à moyen terme va venir booster la cartographie en ligne en faisant tomber un certain nombre de barrières. Mais tout n’est pas fait, et est encore un peu complexe. Mais on y arrive !

À propos de l'auteur

1 commentaire
Ajoutez le votre
  1. Jan Marsch

    Hello Benjamin,
    Regarding Canvas and 3D , I’d like to point you to OSM Buildings, a JS library for displaying schematic 3D buildings on top of maps.
    Regards,
    Jan

Laissez votre commentaire