J’ai ouvert Google Earth en pensant regarder ça quelques minutes. Mauvais calcul. On part de la planète entière, on tourne, on choisit une ville et on est encore là à zoomer dix minutes plus tard.

Les images aériennes et satellites ne sont pas nouvelles. Le tour de force est de donner l’impression qu’elles forment une seule surface continue sans télécharger la planète au complet. Une architecture de niveaux de détail découpe l’imagerie en petites tuiles et construit une pyramide de résolutions.

Au niveau 0, quelques tuiles grossières couvrent le globe. Chaque tuile peut ensuite être divisée en quatre enfants plus précis, un quadtree. La caméra, sa distance et la taille à l’écran déterminent quels nœuds sont assez détaillés. Quand je zoome, le client demande seulement les enfants visibles; quand je recule, il réutilise les parents.

niveau 0             [monde]
                     /  |  |  \
niveau 1          [NO][NE][SO][SE]
                       / | | \
niveau 2          tuiles plus précises seulement où la caméra regarde

Le globe lui-même est un maillage 3D texturé. Le GPU projette ses triangles selon la caméra. Des données d’altitude peuvent déplacer les sommets pour produire le relief. Le moteur élimine les tuiles derrière le globe ou hors du champ, choisit une résolution qui ne dépasse pas beaucoup un pixel source par pixel écran et garde de petites bordures pour éviter des coutures pendant le filtrage.

Le chargement possède des priorités :

1. afficher immédiatement une tuile parent déjà en cache;
2. demander les tuiles visibles au centre;
3. charger les bords qui entreront bientôt dans le champ;
4. remplacer progressivement le parent flou par les enfants détaillés;
5. annuler ou déprioriser les demandes devenues hors écran;
6. conserver les tuiles récentes jusqu’à la limite du cache.

Cette stratégie cache la latence. Attendre chaque image parfaite avant de peindre donnerait une longue page vide. Montrer une version grossière permet de continuer à tourner. Deux réponses peuvent revenir dans le mauvais ordre; le client doit vérifier le niveau et la position avant d’appliquer une tuile, comme dans une interface Ajax.

La quantité de données reste énorme. Les serveurs peuvent distribuer des tuiles statiques depuis plusieurs emplacements et profiter du cache HTTP. Le client envoie un identifiant de tuile et une version plutôt qu’un rectangle arbitraire, ce qui donne une clé stable au cache. Une empreinte ou une longueur détecte un téléchargement tronqué; le fichier temporaire n’entre dans le cache qu’après validation.

Google Earth accepte aussi des repères et formes décrits en KML. Une marque minimale montre comment une donnée métier peut se superposer au globe sans modifier l’imagerie :

<Placemark>
  <name>Montréal</name>
  <Point><coordinates>-73.567,45.501,0</coordinates></Point>
</Placemark>

Les coordonnées suivent longitude, latitude, altitude. Un fichier peut référencer une icône ou un autre réseau; ouvrir un KML non fiable demande donc la même prudence qu’un contenu Web. Des milliers de repères doivent être regroupés ou chargés par région, sinon le CPU et l’écran deviennent la limite même si les images arrivent vite.

Le globe n’est pas une photo instantanée. Les tuiles proviennent de dates, saisons, angles et qualités différents. Une couture ou un bâtiment absent ne signifie pas que le moteur a mal placé la Terre. J’aimerais que chaque couche transporte sa date et sa résolution afin de ne pas tirer une conclusion actuelle d’une image ancienne.

Pour appliquer l’idée ailleurs, je découperais un gros ensemble selon la vue et le niveau de détail, puis je testerais avec un lien lent et coupé. Le produit doit rester navigable avec le cache, afficher une résolution moindre plutôt qu’un trou et ne jamais confondre « tuile récente » avec « donnée récente ». Google Earth impressionne parce que son pipeline choisit sans cesse ce qu’il n’a pas besoin de charger.