Itinéraire pour Personne à mobilité réduite
publié le , mis à jourDécrivez votre problème, votre suggestion
Dans les calculs d'itinéraires, pouvoir activer une option "Personne à mobilité réduite". Et ensuite, voir ce qui est possible dans les calculs: éviter les escaliers, voir si l'arrêt de bus est adapté? tenir compte de place de parking adapté? -> vu les complexités, peut-être démarrer simplement avec la prise en compte en "piéton à mobilité réduite" dans une V1, et ensuite faire évoluer les autres modes dans V2, V3.
Système d'exploitation
No response
Navigateur
No response
laem
Côté itinéraire marche, il faut voir si BRouter propose un profil sans escaliers notamment. Et le créer si ce n'est pas le cas.
Côté transport en commun, Motis le fait déjà. Il faut ajouter l'option à l'interface, au bon endroit, et Motis se chargera d'optimiser le trajet comme il peut :)
ArnaudBlanchard
Comme discuté sur linkedin, ce serait super de pouvoir choisir les profile principalement plats comme pour le vélo.
- Soit proposer plusieurs itinéraires avec plusieurs profils d'altitudes, soit pouvoir pénaliser les pentes dans le calcul. C'est surtout important quand l'itinéraire fait monter pour redescendre.
Je ne peux pas mettre d'image mais je les ai mises dans des commentaires dans le post linkedin: https://www.linkedin.com/feed/update/urn:li:activity:7513860731948285952/?dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287514677568067747840%2Curn%3Ali%3Aactivity%3A7513860731948285952%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287515102282217144320%2Curn%3Ali%3Aactivity%3A7513860731948285952%29
Komoot https://www.komoot.com/fr-fr le fait un peu
[edit par Étienne] voilà les images :
etienneJr
@ArnaudBlanchard L'option
au plus platest disponible depuis ce matin sur le calculateur piéton, pouvez nous tester et nous dire si ça vous parait bien ? En pratique on règle 2 paramètres du calculateur bRouter :downhillcostvalueetuphillcostvalue, @laem les a réglé un peu au hasard, il faudra sûrement quelques itérations pour trouver le bon réglage. D'ailleurs, @laem j'ai l'impression que @ArnaudBlanchard pourrait éventuellement tester directement l'impact des paramètres en testant sur https://brouter.m11n.de/ tu confirmes ?D'ailleurs, @laem j'ai l'impression que @ArnaudBlanchard pourrait éventuellement tester directement l'impact des paramètres en testant sur https://brouter.m11n.de/ tu confirmes ?
Complètement ! Cartes.app est une interface à bRouter et l'interface officielle permet de tout changer à volonté, c'est un super bac à sable.
Effectivement c'est un peu mieux avec l'option merci, mais pas assez fort. La pente ne se réduit qu'un tout petit peu. Par contre si je pars du 2 de la rue plutôt que du 8 alors là la "bonne" pente est choisie.
Ce sera dur de trouver le bon coût de la pente surtout que l'on a pas tous les même problèmes. Ce serait bien à terme de pouvoir régler la force du "au plus plat" ou de proposer plusieurs trajets selon un jeu de forces prédéterminées. Même les piétons bipèdes aiment pouvoir éviter les pentes vraiment trop abruptes.
Je vais essayer de jouer avec un profil de randonneur personnalisé pour voir les différentes options réglable et peut être proposer plusieurs set de réglages
Super merci !
Ce serait bien à terme de pouvoir régler la force du "au plus plat" ou de proposer plusieurs trajets selon un jeu de forces prédéterminées.
Oui c'est dans tous les cas un truc qu'on doit proposer pour le vélo, comme on le fait pour la voiture : plusieurs propositions. bRouter le fait, on n'a juste pas eu le temps de l'implémenter.
Si je pars sur le profil randonneur comme modèle, il semble que je ne peux pas avoir l'intensité de la pente ou le dénivelé comme calcul du coût ( juste la quantité de pente supérieur à uphillcutoff ). Par exemple à l'inverse comment interdire une pente trop forte, j'ai l'impression que l'on ne peut enlever que la quantité.
J'aimerais avoir accès au dénivelé ou au gradient de pente. En tout cas c'est génial, si on peut faire un profil PMR il y a vraiment moyen de faire quelque chose de très personnalisé et utile.
J'imagine qu'il y a une doc quelque part qui indique la liste des variables utilisées par le routeur et comment elles le sont. Ce serait très utile, pour l'instant je ne fais que deviner.
@ArnaudBlanchard wrote in https://codeberg.org/cartes/web/issues/2685#issuecomment-25240807:
J'imagine qu'il y a une doc quelque part
je pense qu'elle est ici, voir notamment la section
The elevation buffer ( From Poutnik's glossary )https://brouter.de/brouter/profile_developers_guide.txt page trouvée via https://brouter.de/brouter/index.html puis https://brouter.de/brouter/costfunctions.htmlBonjour,
J'ai fait pas mal de test en fait la complexité vient du fait que dans le profil "randonneur" les sens interdits et plein d'autres éléments liés au vélo sont pris en compte.
De ce que je vois en tout cas le paramètre important serait: uphillcost plus que uphillcostvalue car uphillcostvalue ne prend pas en compte l'intensité de la montée ce qui est primordial.
Comme dans l'exemple j'ai pris le profil "Randonneur" mais qui ne correspond pas à piéton de Cartes.app ( c'est plus adapté au vélo ). Pourrait-on connaitre le profil utilisé pour piéton de Cartes.app pour que je fasse de vrais modifications applicables.
Merci,
C'est hiking-mountain qui est utilisé sur cartes.app. Avec par défaut, la restriction à des chemins de rando "SAC scale" de 2 ou moins, pour justement éviter la rando.
Oui, "trekking" c'est vélo.
Ok parfait. déjà un premier réglage comme ça ça a l'air bien: J'ai passé le uphillcostvalue de 7 à 30 et passé les cutoffvalue de 3 à 2
On pourrait imaginer un autre réglage "très plat" encore plus agressif avec un uphillcostvalue de 60
Sur quelques tests que j'ai fait 30, ça fait des vrais changements utiles.
as initial point, considered flat speed 4 km/h, climbing speed 600 m /h
assign uphillcostvalue 30 assign uphillcutoffvalue 2 assign downhillcutoffvalue 2 assign downhillcostvalue 7
Merci ! Mais attend, le réglage que j'avais mis (un peu au pif, juste quelques essais) c'était
uphillcostvalue: 100, downhillcostvalue: 100,Donc ça veut dire que j'étais trop agressif ? Tu as adouci l'algo pour tolérer plus de déniv, si je comprends bien ?
De même pour les cutoffvalue, la valeur par défaut c'est 1,5 %. Si je me trompe pas, en mettant 2, tu dis : jusqu'à 2 % ça ne coute rien (au sens algo brouter : chaque propriété génante du parcours a un cout qui le fait privilégier une autre route éventuelle de moindre cout).
Ça te semble cohérent ?
Non pour une raison que je ne comprends pas la version actuellement en ligne ne fonctionne pas. Ça paraît pas encore assez agressif mais le problème est surement ailleurs.
Moi uphillcostvalue à 30 ça suffit pour l'exemple initial en tout cas. Du Dream Café 8 rue des martyrs au CInéma Louxor. 170 boulevard de Magenta. C'est un bon exemple car je connais et à distance quasi égale il y a vraiment une bonne et mauvaise trajectoire. Le modèle "au plus plat actuel" ne trouve pas la bonne solution.
Le profil model sur lequel j'ai changé les valeurs c'est à partir de "Randonnée ( montagne )" (ce que je suppose traduction de "hiking-mountain") mais peut-être qu'il y a un malentendu là dessus ?
Effectivement passer les cutoffvalue à 1.5 c'est surement une bonne idée. Par contre pas besoin de trop pénaliser les descentes, à part si c'est vraiment dangereux, on aime bien.
Mince pardon, hier en bidouillant j'ai commité par erreur les modifs que tu me proposait.
Donc ce qui est en ligne actuellement c'est ça (le vert) :
Et je confirme qu'avec ces valeurs, dans cartes.app, ton trajet qui passait par martys/trudaine sans l'option "au plus plat", passe maintenant par Maubeuge, ce qui est voulu je crois.
Tu peux retester pour confirmer que ça marche pour toi sur cartes.app ?
Effectivement passer les cutoffvalue à 1.5 c'est surement une bonne idée. Par contre pas besoin de trop pénaliser les descentes, à part si c'est vraiment dangereux, on aime bien.
Ce qui veut dire garder le défaut à 1,5 pour la montée, et augmenter le % de descente tolérable ? Jusqu'à combien, 2, ou 3 % ?
Merci beaucoup pour tes tests en tout cas.
J'ai une question très naïve pour toi @ArnaudBlanchard : comment tu images l'interface utilisateur au bon niveau ? Pour que ça soit découvrable par les personnes qui en auront besoin, mais sans que ça soit clivant ?
- on garde en l'état une option "au plus plat" dans le mode piéton ?
- on appelle cette option "fauteuil / PMR", mais toujours dans le mode piéton ?
- on crée un mode spécifique "PMR" qui pourrait avoir plusieurs options plus ou moins agressives ?
Ok laem ça fonctionne maintenan merci ! C'est étonnant car ça aurait du marcher encore mieux avec une valeur de 100. Je vais essayer de l'utiliser pour ma vie de tous les jours.
À Etienne faut voir je vais réfléchir et demander à d'autres. Moi j'aime bien comme ça et c'est ce que je recherchais. Pouvoir personnaliser sans escalier et * au plus plat * ça me paraît suffisant et c'est très bien de ne pas avoir besoin de la catégorie PMR à part avec des risques que ce soit moins maintenu, que ça devienne incompatible avec de nouvelles fonctionnalités etc.
Dans le monde physique en tout cas avoir des aménagements à part ( entrées, toilettes, passage spécial ) ce n'est jamais une bonne idée, car au bout d'un moment c'est laissé à l'abandon, ce n'est pas adapté à des événements exceptionnels, etc ...
Après si on multiplie les options, ce sera peut-être nécessaire de tout regrouper mais ce serait mieux de pouvoir faire des profils personnalisés pas spécifiques PMR. De toute façon 2 PMRs n'ont pas forcément les même besoins (ceux qui ont un fauteuil électrique qui ne passe pas les trottoirs, une roue motorisée et qui prennent les voix de vélo, un fauteuil manuel mais sportif, etc.
Ce sera surement beaucoup plus complexe mais sur la partie transport en commun il faudrait une version sans escalier ou avec la possibilité de demander l'aide à l'accueil ( deux choses différentes d'être autonome ou non ). J'en parle un peu sur un autre topic: https://codeberg.org/cartes/web/issues/863
Je vois que l'on peut avoir un profil encore plus détailler des pentes, c'est génial. Plutôt que d'avoir plusieurs options difficiles à définir, il faudrait afficher deux ou 3 profils de pentes différents dans les résultats ( avec typiquement deux ou 3 valeurs de uphillcostvalue différents ) pour que l'on puisse choisir le profil que l'on préfère.
Rien que les bosses dans les croisements sont prises en compte comme des pentes raides alors que ça dépende de trop de paramètres comme le fait que l'on soit d'un coté du trottoir ou l'autre, etc. Il faudrait négliger ces passages, je testerai les paramètres de buffers, je crois que c'est fait pour ça.
Dans l'exemple donné ça met 4 mètres de pentes très raides alors que c'est négligeable ou ça peut être considéré comme du bruit.
* on garde en l'état une option "au plus plat" dans le mode piéton ? * on appelle cette option "fauteuil / PMR", mais toujours dans le mode piéton ? * on crée un mode spécifique "PMR" qui pourrait avoir plusieurs options plus ou moins agressives ?Oui la marche PMR pour les TeC est facile à ajouter, c'est déjà calculable mais pas affiché. Et créer 2 itinéraires alternatifs, c'est pareil, on n'a juste pas eu le temps de l'ajouter dans l'UI comme on l'a fait pour la voiture.
Dans l'exemple donné ça met 4 mètres de pentes très raides alors que c'est négligeable ou ça peut être considéré comme du bruit.
Pas simple ce sujet, car il y a souvent bel et bien juste 4 mètres de pentes très raides pour le vélo (et donc la marche) et ça peut casser un itinéraire par exemple pour des vélo-bagages ou des randonneurs moins sportifs.