Un point sur une carte, ça prend tout un système

Depuis mon billet sur le GPS en 2002, je garde un œil sur le domaine parce que l’idée me fait encore tripper. Le petit point sur une carte commence à devenir un service, mais ce point est le résultat d’au moins trois systèmes : un récepteur qui calcule, un réseau qui transporte et une application qui interprète.

Un satellite GPS diffuse sa position et une heure très précise. Le récepteur mesure le temps mis par le signal pour arriver. Comme les ondes voyagent à la vitesse de la lumière, un décalage d’une microseconde représente environ 300 mètres. L’horloge d’un appareil ordinaire n’est pas assez précise; le récepteur utilise donc au moins quatre satellites pour résoudre la latitude, la longitude, l’altitude et son propre décalage d’horloge.

Le résultat peut sortir sous forme de phrases NMEA sur un port série. Une lecture simplifiée ressemble à ceci :

$GPGGA,142315,4530.120,N,07334.500,W,1,07,1.4,36.2,M,...

On y trouve l’heure, la position, la qualité du correctif, le nombre de satellites et une mesure de dilution de précision. L’application ne devrait pas garder seulement 45.502, -73.575; elle devrait aussi conserver l’heure, la qualité et l’identité du véhicule.

récepteur GPS -> terminal embarqué -> modem cellulaire
      -> serveur d'acquisition -> historique -> carte et règles métier

Une position peut être exacte et déjà inutile

Prenons un camion qui transmet toutes les 60 secondes. À 90 km/h, il parcourt 1,5 km pendant cet intervalle. Si le réseau garde le message deux minutes dans une zone mal couverte, le point reçu peut avoir plus de quatre kilomètres de retard sur le véhicule. Le serveur doit distinguer l’heure de mesure de l’heure de réception et marquer la donnée comme périmée.

Les immeubles ajoutent le multipath : le signal rebondit avant d’atteindre l’antenne et paraît avoir voyagé plus longtemps. Un tunnel coupe carrément les satellites. Le terminal peut alors conserver les lectures localement et les transmettre au retour du réseau, mais l’application ne doit pas les afficher comme du temps réel. Un cercle d’incertitude, l’âge du point et un symbole différent valent mieux qu’une épingle parfaitement nette et trompeuse.

Le géocodage et la carte ajoutent leurs propres erreurs. Une coordonnée correcte posée sur une route mal numérisée semble fausse. Pour une répartition de flotte, être le véhicule le plus proche « à vol d’oiseau » ne signifie pas être le plus rapide si une rivière ou un sens unique sépare les deux points.

La reprise doit fonctionner sans inventer une trajectoire. Je donnerais un numéro de séquence à chaque lecture, je rejetterais les doublons et j’accepterais les messages arrivés en retard dans l’historique sans déplacer brusquement le point courant vers le passé.

Enfin, la permission doit être une règle du système : quels véhicules sont suivis, pendant quelles heures, qui peut voir l’historique et quand il est supprimé. Le fait qu’un modem puisse envoyer une position n’accorde pas le droit de la garder indéfiniment.

Je reste observateur de ce domaine. Pour un essai, je mesurerais d’abord l’âge et la qualité des lectures dans un tunnel, entre des édifices et hors couverture. La jolie carte viendrait après. Une position n’aide à décider que si l’application montre honnêtement d’où elle vient et à quel point on peut encore lui faire confiance.