Voici le compte rendu du Waze Meetup Europe 2017 (à partir de mes notes et revu et validé par Olivier)
INTRODUCTION
Participants de communauté Française :
Olivier (Bullshoot)
Jean-Pierre (Nomenclator1977)
Votre serviteur
Staff Waze présent :
Daliah, community manager pour notre communauté FR, backup de Shira
Debbie, meetup event coordinator
Gai Berkovitch, COO, membre de l’executif de Waze
Leora, Manager des équipes d’ingénieurie, membre de l’executif de Waze
Tsiki, Ingé routing
Nir Tober, Ingé produit sur le Client
Tamir, Ingé produit WME
Omer, Community Manager
Karen, Wazeopedia & Lithium lead
Gai a réaffirmé que même si Waze mise beaucoup sur Carpool, Waze reste un tout et la communauté garde toute son importance, puisque c’est la contribution de la communauté qui crée la pertinence de Carpool STATISTIQUES EUROPE
Volumes
4,5M de km parcouru par les Wazers
5100 editeurs actifs
55 GC
Variation sur 1 an
-12% d’éditeurs actifs (5800 –> 5100)
-22% d’Area Managers (890 –> 693)
-20% d’éditions (15M –> 12M)
le problème est donc général et pris au sérieux par Waze
Présentation des scores de Map Quality Europe (certain GC ont pris des photos… pas moi donc si vous réussissez à récupérer les screenshot, à mettre ici ). Explications sur le calcul de la mesure de Map Quality:
30% sur la connectivité (connectivity) : classique, on connait.
15% sur la couverture (coverage) : routes tracées, POI positionnés, etc…
20% sur l’exactitude (correctness) : volume de MPs, de URs, etc…
15% sur la complétude (completeness) : nommage des segments, n° de rue, et autres propriétés des segments, etc…
20% sur la fraicheur (freshness) : activité d’édition récente sur le segment, en particulier lors de l’apparition de nouvelle feature d’édition.
FONCTIONNALITE ROUTING
Nouvelle fonctionnalité en cours de test Bêta aux US :
Restriction par voie (lane) sur un même segment.
Permissions (accréditation) de rouler sur un segment (conducteur autorisé/habilité à rouler sur un segment, indépendamment du type de véhicule)
Prise en compte de nouveaux type de véhicule
Gai a confirmé qu’il n’y avait pas de volonté à gérer les camions dans Waze. Ce n’est pas dans la stratégie de Waze. Il y a des contraintes légales à le faire, en particulier sur l’obligation de les amener efficacement à la bonne destination, avec tous les enjeux que cela représente (hauteurs sous pont à respecter, zones interdites au transit, etc…). Donc inutile d’insister pour avoir le type PL utilisé. Tamir confirme que Waze sait identifier, dans les stats temps-réel par les écart-types, les poids-lourds qui circulent sur un axe afin de ne pas les prendre en compte dans les moyennes de vitesse des segments.
Ajouts de nouvelles fonctionnalité aux Junctions Box:
Restriction par voie (lane) sur un même segment.
possibilité de faire de instruction override dans la JB
possibilité de faire des closures sur certains axes traversants la JB
possibilité de configurer des time-based restriction dans la JB
le polygone de la JB est amélioré pour suivre le pourtour des routes qui composent la JB, plutôt que de faire un gros rectangle qui englobe tout (et qui risquaient d’englober des segments qui n’ont rien à faire dans la JB)
pour le moment la JB est limité à 18 segments (entrant + sortant). Si nous rencontrons des situations où nous aurions besoin de davantage de segments, il faut le leur remonter.
possiblité d’éditer les segments à l’intérieur de la JB (sans avoir à supprimer puis récrer la JB)
pas de JB sur les Rond-Points pour le moment
Tamir confirme qu’il n’y a plus aucune raison de limiter l’usage de la JB. Les propos d’Irad au début de la JB il y a 2 ans (disant qu’il fallait limiter l’usage des JB parce que cela nécessite beaucoup de temps de calcul, etc…) sont désormais obsolette et le staff confirme qu’il ne faut pas hésiter à l’utiliser.
La fiabilité de l’ETA sera amélioré par l’usage des JB et par le nettoyage de la carte en limitant les segments inutiles. Tamir confirme que, même s’il n’y a plus de pénalités par noeud ( pour être exact : une fois que du traffic est passé dessus et qu’il y a une information de temps de transit historisée, sinon c’est entre 2 et 5 secondes en fonction du type de segment), en revanche plus un segment est redécoupé, plus on cumule des incertitudes statistiques du temps de transit de chaque segment, d’autant plus que Waze considère l’approche pessimiste dans les moyennes renvoyées par chaque segment. Donc l’ETA est d’autant plus fiable qu’il y a un nombre limité de segments parcouru.
Delayed Segment:
déjà prêt dans le routing server
gérer l’attente qu’un segment soit ouvert d’ici peu dans le routage
Au lieu de bloquer une route (et donc de l’exclure du routing), le système prend en compte l’hypothèse où l’on attend qu’elle soit ouverte et avise si c’est plus rentable d’attendre que de faire le détour
(exemple concret pour nous : le Gois –> est qu’on déroute par le pont alors que le Gois va ouvrir dans 2 minutes ?)
optimisation du calcul des itinéraires longs:
le but est d’éviter les timeout dans les calculs d’itinéraire long à cause du temps nécessaire pour calculer la route principale et les alternatives.
Détour traversant les frontières:
le but est d’éviter les situations où détour fait sortir du pays pour y revenir un peu plus loin. Il s’agira d’une configuration par pays.
Pénalités sur les offroads:
il y a toujours une pénalités sur les offroads, indépendamment des users settings du Wazer dans son App.
il sera possible de désactiver la navigation offroad pays par pays, en particulier dans les pays où il y a une infrastructure routière suffisamment développé pour se dire que le offroad est marginal (c’est le cas en France)
Pedestrian & Boardwalk:
Objectif : cartographier les zones piétonnes (résidence, centre commerciaux ouverts, etc…) et assurer un routage au plus prêt du conducteur.* Plutôt que d’amener le wazer au plus prêt géométiquement de sa destination non-routable, si la destination est sur un pedestrian et que ce pedestrian est connecté au réseau routier, alors le wazer sera améné à cette connection entre le réseau pedestrian et le réseau routier.
Conséquence, il faut mapper ET connecter le réseau pedestrian sur le réseau routier, là où les chemins permettent de rejoindre la route et vice-vers-ca
Pour éviter la multiplication des découpes de segments (et les conséquences sur le routage qu’on connait), ils introduisent un nouveau “layer” de connectivité qui se matérialise par un nouveau type de noeud; Lorsqu’un pedestrian rejoint une route, il est connecté à la route par un noeud spécifique qui n’est pas pris en compte dans le routing. pour le routing server, le segment n’est pas découpé en 2 et les infos restent identiques. Pour nous dans WME c’est transparent.
on ne pourra pas connecter le pedestrian à tous les types de segments : décision par pays des types de segments connectables (cf la question récente du staff sur ce sujet et notre réponse : les freeways uniquement)
Optimisation des alternatives roads
Le client va recalculer à intervalle régulier 3 alternatives roads en avance, de manière pouvoir les afficher et permettre de switcher sans attente.
il y aura la possibilité de tagger l’itinéraire favori
l’itinéraire favori sera automatiquement proposés dans les 3 alternatives
l’itinéraire favori n’est pas préféré pour autant : il prend sa place dans la liste en fonction du temps et de la distance qu’il représente.
optimisation du recalcul d’itinéraire pour éviter que, lorsque le routing server recalcule notre itinéraire (suite à un bouchon qui se résorbe par exemple), il ne vienne pas finalement nous ramener sur l’itinéraire primaire (celui fourni par défaut au départ) alors qu’on avait fait le choix d’un itinéraire alternatif.
Travaux pour obtenir la “naïve route” dans les choix d’itinéraire
le but est de proposer dans les itinéraires, celui qui semble “évident” quand un humain regarde une carte. C’est pas forcement le plus efficace, mais ca semble être celui par défaut pour un conducteur qui n’utiliserait pas de GPS et qui se contenterai d’avoir une carte papier sur les cuisses.
Projet (later than soon) d’avoir les prix des péages sur les toll road.
Waze utilise les informations de Google Traffic partout où il n’a pas de remontée d’information temps-réel par son propre réseau de Wazer.
Projet de traitement optimisé des détours. Identifier pouquoi il y a un détour, identifier les endroits où les wazers ne suivent pas le détour proposé par Waze, identifier les endroits où les wazers provoquent un recalcul d’itinéraire avec la meme destination, etc… FONCTIONNALITE CLIENT
En vrac :
projet d’ajouter davantage d’information sur la raison du bouchon dans la traffic bar (la barre de progression dans le bouchon)
projet de gérer des limites de vitesses variables dans le temps (time-based speed limits)
projet de gérer des zones de limites de vitesses (comme nos zones 30)
projet de customiser les signalements possibles (dans l’App) en fonction des pays et en fonctions des saisons
projet de gérer les zones de restrictions de circulation pour la qualité de l’air (Critair en France, plaques pair/impaire, ZTL, etc…)
Beta lancé pour une gestion améliorée de l’ASR
projet d’amélioration du signalement sur l’App lorsqu’on a pas de couverture réseau au moment du signalement (offline reporting)
projet de “tap on turn” sur l’App : permettrait, à partir de la liste des instructions de l’itinéraire, en touchant une des instructions, de zoomer automatiquement sur la carte à l’endroit où cette instruction devrait se déclencher
projet d’amélioration de la représentation des alternatives routes sur l’App : l’idée serait de monter au Wazer les différentes routes sur la carte, un peu comme sur livemap.
projet d’amélioration de l’écran d’ETA (qui affiche beaucoup de contenu et qu’il faut rendre plus lisible et plus ergonomique)
projet de rendre le “drive menu” contextuel : par exemple, on propose des parkings quand on est proche de la fin du trajet, en revanche on propose des pompes à essences si on affiche le drive menu au milieu du trajet (ou des restaurants si il est midi, etc…)
Projet d’afficher des popups de vigilance sur l’allumage des phares de circulation dans les zones où c’est obligatoire (par exemple les tunnels, ou certaines routes des Landes chez nous)
Projet d’amélioration du rendu visuel de la carte sur le client
Projet d’afficher l’itinéraire en “Snail Trail” c’est à dire que la portion de route déjà empruntée sera d’une couleur différente (par exemple violet clair) de la couleur du reste de l’itinéraire à suivre (violet foncé). ainsi cela rend plus lisible l’itinéraire à suivre au niveau des échanges complexes ou, vu de dessus, l’itinéraire se recoupe.
Projet d’avoir un Driver Summary dans l’App : des représentations graphiques sur le stats de conduite du Wazer
Community Workshop sur le MENTORING
J’ai amorcé la discussion sur un topic aujourd’hui
Je vous ferais un débrief exhaustif du sujet quand j’aurai reçu le CR que Debbie doit nous envoyer des notes prises dans chaque atelier.
En revanche, je vous en supplie, à la lecture de ces informations, il y a de nombreuses choses d’ores et déjà en production, qui sont des nouveautés.
Merci de NE PAS vous jeter sur leur intégration massive partout dans le pays sans que le wiki ait été mis à jour, et que les autres éditeurs non Champs ne comprennent pas et viennent le reprocher ensuite.
Je ne campe pas, pour la Xième fois, sur mes positions.
Désormais, depuis ce jour, 15h28, l’explication technique officielle (relayée au plus juste je l’espère par David) a été donnée, et il ne me dérange absolument pas de m’y plier et de précher la bonne parole.
Ca c’est un VRAI argument technique et officiel (fourni par le staff, qui a mon sens est le seul a avoir l’étiquette “officiel”) qui vaut pour application. Tout autre argument (Wazer n’a pas besoin, Ax est suffisant, le comuters, la météo du jour, etc…) sont insignifiants.
Donc, il faut se mettre à écrire cela dans le Wiki. Rapidement. Ca clouera le bec à tous les débat à ce sujet.
Rajouter aussi que les ponts au dessus des rivières doivent être détruits pour gagner 2 noeuds. Mais que du coup, en cas d’inondation, on ne pourra pas les fermer avec précision. Faut en parler à Riri70… :mrgreen:
C’était une info qu’on a eu au meetup FR à Paris. et qui était de notoriété publique. moins y’a de segment mieux c’est. Je suis en attente d’une réponse à ma demande auprés de Karen et Daliah pour t’apporter le tampon officiellement signé du staff.
Mais puisque c’est écrit dans un compte rendu du dernier meetup Europe. y’a plus besoin d’attendre.
A ton avis, mes infos, en tant que coordinator, je les ai d’où ? de mon cerveau et de mes idées qui valent pour application ou bien du staff directement ?
). Explications sur le calcul de la mesure de Map Quality: