demotera / mobirennes

Calcul d'itinéraire à Rennes
http://www.mobirennes.com
GNU General Public License v3.0
5 stars 1 forks source link

Faciliter un paramétrage plus fin #5

Closed Tristramg closed 13 years ago

Tristramg commented 13 years ago

Le paramétrage actuellement a été fait le pouce levé. Même si ça semble pas mal, c'est perfectible. Du coup, il faudrait

pplr commented 13 years ago

La raison du commit était que ce lien ne servait à rien mis à part débugguer l'appli. Je peux afficher un lien vers la recherche dans un élément masqué de la page. Ça permettra de pouvoir rejouer un itinéraire donné.

Tu t'attend à quoi exactement pour le mode débug ?

Tristramg commented 13 years ago

Le lien permet de donner un exemple sympa, d'envoyer par mail à quelqu'un qui a la flemme de chercher mais qui veut bien faire l'effort de cliquer sur un lien, de remonter des itinéraires pas cohérent par quelqu'un qu'il ne développe pas dessus. Je pense donc que c'est indispensable d'avoir un truc accessible à tout le monde (après qu'on ait une url en bas, ou que ça change la barre d'adresses, ça n'a aucune importance). Donc pas de lien caché.

Pour le debug, juste avoir quelque part la valeur des objectifs de chaque itinéraire (du coup ça peut être caché, mais ça serait cool que ce soit moins pénible que l'option firebug ;) )

paul-r-ml commented 13 years ago

Je profite de la nouvelle fonctionnalité pour donner un exemple de redondance de trajet :

http://www.mobirennes.com/?dep=-1.7128479843129%2C48.103408999018&dest=-1.6452589416511%2C48.111919828273&time=14%2F03%2F2011+12%3A58

On peut aisément éliminer ça depuis la couche appelante (service web python en l'occurence), mais avant de le faire il faut voir si ça ne cache pas un petit pépin dans la couche appelée (le moteur de calcul). Qu'en pense-tu Herr Ingenior Doctor ?

Tristramg commented 13 years ago

Oué, il faut voir au niveau du calcul d'itinéraire. Normalement les inégalités sont strictes pour éviter ce genre de cas. J'ai pas de firebug sous la main pour voir quels sont les coûts, mais je m'attaque à ce problème

2011/3/14 paul-r-ml reply@reply.github.com:

Je profite de la nouvelle fonctionnalité pour donner un exemple de redondance de trajet :

http://www.mobirennes.com/?dep=-1.7128479843129%2C48.103408999018&dest=-1.6452589416511%2C48.111919828273&time=14%2F03%2F2011+12%3A58

On peut aisément éliminer ça depuis la couche appelante (service web python en l'occurence), mais avant de le faire il faut voir si ça ne cache pas un petit pépin dans la couche appelée (le moteur de calcul).  Qu'en pense-tu Heir Ingenior Doctor ?

https://github.com/demotera/mobirennes/issues/5#comment_868633

pplr commented 13 years ago

Le dernier itinéraire proposé est intéressant : http://www.mobirennes.com/?dep=-1.6928494338989%2C48.109140352153&dest=-1.6589918518069%2C48.11312326614&time=14%2F03%2F2011+23%3A19

Tristramg commented 13 years ago

En prenant le cas de Paul, on a comme objectifs :

Il y a des cas où on gagne 2 secs pour 7 de pénibilité (14m de vélo en plus, ou 14m de marche). J'augmente le rapport à 1 pour 4 (contre 1 pour 2 avant). Ça filtera ces solutions. Après, je ne m'explique pas pourquoi un chemin plus long serait plus court en temps (ça devrait être strictement proportionel). On va mettre ça sur le compte d'arrondis, mais faut le garder à l'œil. Il y a quand même un décalage de l'ordre de 2%.

Dans le cas de Pierre

C'est déjà beaucoup plus délicat. Le trajet 3 met 22 secs de plus que le trajet 2 et on économise 140m de marche. Là il faut voir : est-ce qu'on passe carrément à un ration de 1 pour 8 ? Je suis un peu réticent. Je propose de rester sur du 1 pour 4 et on voit si ça arrive souvent ou pas.

Enfin pour le dernier cas (là où on prend le bus dans les deux sens), il disparait avec le ratio 1 pour 4

paul-r-ml commented 13 years ago

Salut,

Tristramg> Après, je ne m'explique pas pourquoi un chemin plus long Tristramg> serait plus court en temps (ça devrait être strictement Tristramg> proportionel). On va mettre ça sur le compte d'arrondis, mais Tristramg> faut le garder à l'œil. Il y a quand même un décalage de Tristramg> l'ordre de 2%.

En effet, je ne m'explique pas non plus cette divergence. S'il y a plus de noeuds sur le chemin, il y a peut-être plus d'additions avec arrondis ... Enfin, c'est quand même bizare à la fin. Est-ce possible de travailler en valeurs exactes ?

Tristramg> Dans le cas de Pierre [1173, 1, 0, 1621.010009765625] [1846, Tristramg> 1, 0, 1062.8375244140625] [1868, 1, 0, 926.3221435546875] Tristramg> [1975, 2, 0, 595.4278564453125]

Tristramg> C'est déjà beaucoup plus délicat. Le trajet 3 met 22 secs de Tristramg> plus que le trajet 2 et on économise 140m de marche. Là il Tristramg> faut voir : est-ce qu'on passe carrément à un ration de Tristramg> 1 pour 8 ? Je suis un peu réticent. Je propose de rester sur Tristramg> du 1 pour 4 et on voit si ça arrive souvent ou pas.

Dans le cas proposé par pierre, je pense que les trajets sont suffisamment différents pour que ce soit acceptable pour l'utilisateur. (hormis le retour bus ;) )

Peut-être qu'on peut avoir une reflexion sur l'interface qui propose les trajets. En particulier, je pense qu'on peut les regrouper en classes, une classe étant caractérisée par l'enchainement des lignes / modes. Dans le cas de pierre, on pourrait proposer un seul trajet Marche-Ligne_4-Marche dans le menu, et faire apparaitre d'une façon ou d'une autre les alternatives pour cette classe. Dans ce cas, il s'agirait de souffler à l'utilisateur qu'il peut aussi descendre plus loin.

Paul

Tristramg commented 13 years ago

Grace à ce we, j'ai pu assez me desintoxiquer des ordinateurs pour m'y remettre.

J'ai trouvé le coupable : il y avait un int qui trainait à la place de float... Ça fait le 2e bug dans l'algo :'(

Entre ça, et l'affinage des paramètres dans le scenario, les résultats devraient être nettement meilleurs