Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet Antoine Riche via Talk-fr 

Merci de ton retour.

On peut faire un fil spécifique sur Talk-fr (c'est peut-être mieux 
d'utiliser la page de discussion pour des évolutions plutôt que des 
clarifications ?) : je vais envoyer un mail dédié.


Pour le schéma il y a bien un highway=crossing sur chacun des nœuds 
représentés par un passage piéton. J'ai mis à jour le schéma : 
https://wiki.openstreetmap.org/wiki/File:Sidewalk_crossing-FR.png . 
C'est plus clair comme ça ?


Antoine.

Le 25/06/2019 à 18:17, osm.sanspourr...@spamgourmet.com a écrit :


Tu veux qu'on en discute comment ? En direct ? Sur talk-fr (avec un 
fil spécifique ;-)), sur la page de discussion ?


Sur la première image :


J'ai du mal à comprendre : n'est-ce pas plutôt un nœud commun au 
chemin séparé (highway=footway) et à la route (highway=*, sidewalk=*) 
qui est tagué crossing=) ? Et grosso-modo juste la petite partie entre 
le croisement des deux trottoirs séparés et et les rues qui doivent 
être en footway=crossing c'est à dire la partie linéaire correspondant 
aux zébras sur la route ?


Le 25/06/2019 à 16:17, Antoine Riche via Talk-fr - 
talk-fr@openstreetmap.org a écrit :


Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section 
 
qui dit explicitement que area:highway n'est *pas* fait pour le 
routing, alors que la combinaison de highway=* et area=yes peut être 
utilisée pour le routing surfacique.


Je suis d'accord aussi sur une approche pragmatique : conserver des 
éléments linéaires qui permettent aux principaux outils de calcul 
d'itinéraires de fonctionner, sans pour autant tracer toutes les 
routes possibles. Et permettre aux logiciels qui font du routing 
surfacique de produire des itinéraires plus réalistes. Il faut pour 
cela connecter les routes linéaires aux places surfaciques en 
partageant un node.


C'est le moment de vous présenter la page de recommandations pour le 
routage piéton 
, 
qui inclut une grosse section sur le routage surfacique, prend en 
compte le indoor comme le outdoor, et inclut une dizaine de schémas. 
Cette page a été présentée lors du SOTM à Montpellier, la 
présentation correspondante est téléchargeable avec ce lien 
.


Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes 
soins puis rajouté par les services de la métropole qui utilise des 
extractions pour ses propres outils de routing (non OSM compliant) 
et qui existe historiquement. Donc les linéaires correspondent à une 
nécessité de leurs outils pour le routing et je pense pour 
l'intermodalité (adresse vers adresse). (non compatible avec de 
l'itinéraire polygonale)


D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a 
aussi des tracés en double pour palier au problème d'affichage des 
noms (linéaire plus zone en dessous)


L'autres système qui a encore d'autres implications c'est 
*area:highway=**.


Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut 
mieux faire un post traitement sous forme de maille avec détection 
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit 
sur ta capture d'écran.





Le mer. 19 juin 2019 à 16:54, lenny.libre > a écrit :



Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2
accès sur la place à quoi bon tracer un chemin fictif qui n'est
pas nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed

Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet osm . sanspourriel 

Tu veux qu'on en discute comment ? En direct ? Sur talk-fr (avec un fil
spécifique ;-)), sur la page de discussion ?

Sur la première image :

https://wiki.openstreetmap.org/w/images/5/5c/Sidewalk_crossing-FR.png

J'ai du mal à comprendre : n'est-ce pas plutôt un nœud commun au chemin
séparé (highway=footway) et à la route (highway=*, sidewalk=*) qui est
tagué crossing=) ? Et grosso-modo juste la petite partie entre le
croisement des deux trottoirs séparés et et les rues qui doivent être en
footway=crossing c'est à dire la partie linéaire correspondant aux
zébras sur la route ?

Le 25/06/2019 à 16:17, Antoine Riche via Talk-fr -
talk-fr@openstreetmap.org a écrit :


Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section

qui dit explicitement que area:highway n'est *pas* fait pour le
routing, alors que la combinaison de highway=* et area=yes peut être
utilisée pour le routing surfacique.

Je suis d'accord aussi sur une approche pragmatique : conserver des
éléments linéaires qui permettent aux principaux outils de calcul
d'itinéraires de fonctionner, sans pour autant tracer toutes les
routes possibles. Et permettre aux logiciels qui font du routing
surfacique de produire des itinéraires plus réalistes. Il faut pour
cela connecter les routes linéaires aux places surfaciques en
partageant un node.

C'est le moment de vous présenter la page de recommandations pour le
routage piéton
,
qui inclut une grosse section sur le routage surfacique, prend en
compte le indoor comme le outdoor, et inclut une dizaine de schémas.
Cette page a été présentée lors du SOTM à Montpellier, la présentation
correspondante est téléchargeable avec ce lien
.

Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :

Pour l'exemple de Montpellier, les tracés ont été supprimés par mes
soins puis rajouté par les services de la métropole qui utilise des
extractions pour ses propres outils de routing (non OSM compliant) et
qui existe historiquement. Donc les linéaires correspondent à une
nécessité de leurs outils pour le routing et je pense pour
l'intermodalité (adresse vers adresse). (non compatible avec de
l'itinéraire polygonale)

D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a
aussi des tracés en double pour palier au problème d'affichage des
noms (linéaire plus zone en dessous)

L'autres système qui a encore d'autres implications c'est
*area:highway=**.

Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut
mieux faire un post traitement sous forme de maille avec détection
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit
sur ta capture d'écran.




Le mer. 19 juin 2019 à 16:54, lenny.libre mailto:lenny.li...@orange.fr>> a écrit :


Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès
sur la place à quoi bon tracer un chemin fictif qui n'est pas
nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ?

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :

Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne
devrais pas en parler ... , je serais bien

Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet Antoine Riche via Talk-fr 

Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section 
 
qui dit explicitement que area:highway n'est *pas* fait pour le routing, 
alors que la combinaison de highway=* et area=yes peut être utilisée 
pour le routing surfacique.


Je suis d'accord aussi sur une approche pragmatique : conserver des 
éléments linéaires qui permettent aux principaux outils de calcul 
d'itinéraires de fonctionner, sans pour autant tracer toutes les routes 
possibles. Et permettre aux logiciels qui font du routing surfacique de 
produire des itinéraires plus réalistes. Il faut pour cela connecter les 
routes linéaires aux places surfaciques en partageant un node.


C'est le moment de vous présenter la page de recommandations pour le 
routage piéton 
, 
qui inclut une grosse section sur le routage surfacique, prend en compte 
le indoor comme le outdoor, et inclut une dizaine de schémas. Cette page 
a été présentée lors du SOTM à Montpellier, la présentation 
correspondante est téléchargeable avec ce lien 
.


Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes 
soins puis rajouté par les services de la métropole qui utilise des 
extractions pour ses propres outils de routing (non OSM compliant) et 
qui existe historiquement. Donc les linéaires correspondent à une 
nécessité de leurs outils pour le routing et je pense pour 
l'intermodalité (adresse vers adresse). (non compatible avec de 
l'itinéraire polygonale)


D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a 
aussi des tracés en double pour palier au problème d'affichage des 
noms (linéaire plus zone en dessous)


L'autres système qui a encore d'autres implications c'est 
*area:highway=**.


Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut 
mieux faire un post traitement sous forme de maille avec détection 
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit 
sur ta capture d'écran.





Le mer. 19 juin 2019 à 16:54, lenny.libre > a écrit :



Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès
sur la place à quoi bon tracer un chemin fictif qui n'est pas
nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :

Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne
devrais pas en parler ... , je serais bien incapable de faire ces
outils" donc je ne suis peut-être pas technique, mais je remarque
simplement qu'il y a des outils qui font sans ces "chemins"

il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la

Re: [OSM-talk-fr] routage surfacique

2019-06-21 Par sujet Brice MALLET 

Le 19/06/2019 à 16:52, lenny.libre a écrit :
Tout produit est améliorable (tout comme mes contributions), je vais 
donc continuer à faire comme d'hab, je ne créerais pas de chemins 
virtuels et je n’effacerais pas ceux des copains.


Bonne conclusion.
Il m'est arrivé de supprimer des chemins virtuels mais maintenant je les 
laisse.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-19 Par sujet osm . sanspourriel 

Le 19/06/2019 à 14:34, Phyks - ph...@phyks.me a écrit :


Je mets volontairement de côté une place aussi complexe que
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal
au passage…)


Ce n'est pas le rendu qui a un soucis, c'est le concepteur.

Car les inners ne sont pas disjoints. Donc tu as une partie qui est
décrite comme étant à la fois dedans et dehors : la partie commune est à
la fois limite intérieure au nord/extérieure au sud et limite extérieure
au nord/intérieure au sud.

Il faudrait créer une zone comportant toute la place qui n'est pas de
niveau et la mettre en inner de la relation.

Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-19 Par sujet lenny.libre 


Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.
A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même 
quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis
Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la 
place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux 
calculateurs)
Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais 
pas en parler ... , je serais bien incapable de faire ces outils" donc 
je ne suis peut-être pas technique, mais je remarque simplement qu'il y 
a des outils qui font sans ces "chemins"

il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


alors quehttps://moodwalkr.com/@montpellier/itineraire
peut calculer un itinéraire

https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
j'espère que tu partageras mon avis que l'amélioration par
rapport à une représentation filaire ne saute pas aux yeux
alors que le point de départ et d'arrivée sont accessible
en ligne droite sans obstacle.


Mais non, je ne partages pas ton avis, pas plus droit avec OSRM,


PS: je n'ai pas chercher à mettre l'outil en difficulté,
j'ai juste demandé la place et une adresse de la place.


Peut-être parce que la partie pour aller à une adresse précise sur une 
place est améliorable, (alors qu'il permet de faire des recherches 
d'itinéraire par thèmes.)


Tout produit est améliorable (tout comme mes contributions), je vais 
donc continuer à faire comme d'hab, je ne créerais pas de chemins 
virtuels et je n’effacerais pas ceux des copains.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-19 Par sujet Jérôme Seigneuret 
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes soins
puis rajouté par les services de la métropole qui utilise des extractions
pour ses propres outils de routing (non OSM compliant) et qui existe
historiquement. Donc les linéaires correspondent à une nécessité de leurs
outils pour le routing et je pense pour l'intermodalité (adresse vers
adresse). (non compatible avec de l'itinéraire polygonale)

D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a aussi
des tracés en double pour palier au problème d'affichage des noms (linéaire
plus zone en dessous)

L'autres système qui a encore d'autres implications c'est *area:highway=**.

Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut mieux
faire un post traitement sous forme de maille avec détection d’obstacle
pour générer du tracé virtuel plutôt que ce que l'on voit sur ta capture
d'écran.




Le mer. 19 juin 2019 à 16:54, lenny.libre  a écrit :

>
> Le 18/06/2019 à 20:33, marc marc a écrit :
>
> j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
> mais aucun des 4 itinéraires n’atteint l'itinéraire réel
> alors que ce sont 2 points de osm de la place.
> donc même ce site a du limiter le nuage de way représentant la place.
> alors imagine les dégâts si tu routes entre Paris et Monpellier
> en surfacique.
>
> A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même
> quand j'étais jeune, je ne le faisais pas).
>
> Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :
>
> Le 18.06.19 à 18:48, lenny.libre a écrit :
>
> donc pour ma part, les routes donnant sur une place
> se rejoignent en un point + souvent place=square
> c'est une représentation imparfaite, mais c'est
> à l'heure actuelle sans doute le meilleur compromis
>
> Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la
> place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux
> calculateurs)
>
> Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ?
>
> les évolutions des tags dans osm se font généralement
> - soit par des tags supplémentaires (highway puis maxspeed
> puis lanes puis turn:lanes par ex)
> - soit par un changement de tags (par ex power=sub_Station
> divisé en 2 power=substation et power=generator).
> Si on suit cette logique, c'est area:highway qui devrait
> être utilisé pour une transitions sans dégradation.
>
> casser en disant "yaka faire du routage surfacique",
> c'est méconnaître ce que cela implique techniquement :
>
> Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais
> pas en parler ... , je serais bien incapable de faire ces outils" donc je
> ne suis peut-être pas technique, mais je remarque simplement qu'il y a des
> outils qui font sans ces "chemins"
>
> il y a un gros travail de prétraitement à faire.
> je ne retrouve plus hélas l'article qui était publiée sur osmweekly
> mais la moindre place avec qlq rues est transformée en un nuage
> de way qui connectent tous les paires de points de la surface.
> en passant, cela veux dire aussi qu'une place surfacique
> avec 8 nœuds consomme 9x l'espace disque et mémoire
> comparé à sa version linéaire et ce n'est pas en un claquement
> de doigt qu'on augmente la puissance d'un serveur gratuit.
>
> je pense que les outils continueront de s'améliorer simplement
> à la demande de leur utilisateur, en fonction des ressources dispo.
>
>
> alors quehttps://moodwalkr.com/@montpellier/itineraire
> peut calculer un itinéraire
>
> https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
> j'espère que tu partageras mon avis que l'amélioration par
> rapport à une représentation filaire ne saute pas aux yeux
> alors que le point de départ et d'arrivée sont accessible
> en ligne droite sans obstacle.
>
> Mais non, je ne partages pas ton avis, pas plus droit avec OSRM,
>
> PS: je n'ai pas chercher à mettre l'outil en difficulté,
> j'ai juste demandé la place et une adresse de la place.
>
> Peut-être parce que la partie pour aller à une adresse précise sur une
> place est améliorable, (alors qu'il permet de faire des recherches
> d'itinéraire par thèmes.)
>
> Tout produit est améliorable (tout comme mes contributions), je vais donc
> continuer à faire comme d'hab, je ne créerais pas de chemins virtuels et je
> n’effacerais pas ceux des copains.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-19 Par sujet Phyks 

Bonjour,


casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


Dans la plupart des cas, le routage surfacique n'est pas un problème 
quand même. Je mets volontairement de côté une place aussi complexe que 
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal 
au passage…) pour se concentrer sur des espaces sans trous (tels que les 
espaces dans l'erreur Osmose initiale 
https://osmose.openstreetmap.fr/fr/map/#item=1270=18=47.497894=-0.580999=1%2C2%2C3==).



La plupart des moteurs de routage ne vont pas gérer le routage 
surfacique à travers la place (qui est un problème compliqué). En 
revanche, tous vont pouvoir traiter la place comme un way fermé (le 
contour) et tous savent a priori emprunter des portions de way. Du coup, 
le routage ne sera pas "joli" (on ne va pas traverser la place comme on 
le voudrait, simplement contourner en suivant la bordure), mais le 
routage restera néanmoins fonctionnel.


Dans un cas simple comme ceci, à mon avis, il n'y a aucune raison de 
tracer des continuités des chemins à travers les places, si ce n'est 
alourdir la base avec des ways inutiles (et qui n'existent pas sur le 
terrain). La description en termes d'air a une réelle plus value 
(notamment pour le rendu, mais pas que), et reste parfaitement 
utilisable, à condition que les aires portent bien les attributs 
corrects (highway et droits d'accès).


Sur un cas similaire à l'exemple initial d'Osmose :
* BRouter suit le contour, 
http://brouter.de/brouter-web/#map=19/45.77393/3.08337/standard=3.083773,45.77412;3.083596,45.773869
* Géovélo aussi, 
https://www.geovelo.fr/clermont/itinerary/search?profile=MEDIAN=TRADITIONAL=45.774108,3.08372%7C45.7739,3.0836
* GraphHopper et OSRM aussi, 
https://www.openstreetmap.org/directions?engine=graphhopper_foot=45.77411%2C3.08376%3B45.77387%2C3.08360



Mon avis serait donc que sur des places simples (sans trou), il suffit 
de connecter le polygone aux chemins voisins et tout tracé de chemin en 
travers du polygone relève plutôt du "tag to router", en créant des 
chemins qui amélioreront le rendu du routage, mais en aucun cas sa 
justesse.


D'ailleurs, malgré l'erreur Osmose, le routage se fait très bien 
http://brouter.de/brouter-web/#map=19/47.49783/-0.58158/standard=-0.581248,47.497738;-0.581433,47.498012.



Ma remarque ne tient plus évidemment lorsqu'on considère des surfaces 
avec des trous (multipolygone) où le routage est épouvantable et 
catastrophique s'il n'y a pas de chemins intérieurs "fictifs", comme le 
montre 
http://brouter.de/brouter-web/#map=17/48.84022/2.32019/standard=2.319813,48.841791;2.321146,48.841137=hiking-beta 
par exemple (BRouter ne gère pas le routage surfacique). Ce point est 
beaucoup plus sujet à débat à mon avis et des chemins "fictifs" 
pourraient être justifiés, même si certains ont des avis assez tranchés 
sur la question https://www.openstreetmap.org/note/1654211.

--
Phyks

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-18 Par sujet marc marc 
j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

Le 18.06.19 à 20:25, osm.sanspourr...@spamgourmet.com a écrit :
> Marc j'ai fait comme toi, écrit à peu près le même message et me suis 
> rendu compte avant de l'expédier que c'était l'ergonomie de l'outil et 
> non l'outil qui péchait.
> 
> Car là il te montre 4 trajets possibles : le plus court, le plus calme, 
> le plus touristique...
> 
> Il faut cliquer à Gauche sur le mode fin que tu souhaites pour qu'il 
> mette en évidence un seul des 4 trajets.
> 
> Jean-Yvon
> 
> Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :
>> Le 18.06.19 à 18:48, lenny.libre a écrit :
 donc pour ma part, les routes donnant sur une place
 se rejoignent en un point + souvent place=square
 c'est une représentation imparfaite, mais c'est
 à l'heure actuelle sans doute le meilleur compromis
>>> Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ?
>> les évolutions des tags dans osm se font généralement
>> - soit par des tags supplémentaires (highway puis maxspeed
>> puis lanes puis turn:lanes par ex)
>> - soit par un changement de tags (par ex power=sub_Station
>> divisé en 2 power=substation et power=generator).
>> Si on suit cette logique, c'est area:highway qui devrait
>> être utilisé pour une transitions sans dégradation.
>>
>> casser en disant "yaka faire du routage surfacique",
>> c'est méconnaître ce que cela implique techniquement :
>> il y a un gros travail de prétraitement à faire.
>> je ne retrouve plus hélas l'article qui était publiée sur osmweekly
>> mais la moindre place avec qlq rues est transformée en un nuage
>> de way qui connectent tous les paires de points de la surface.
>> en passant, cela veux dire aussi qu'une place surfacique
>> avec 8 nœuds consomme 9x l'espace disque et mémoire
>> comparé à sa version linéaire et ce n'est pas en un claquement
>> de doigt qu'on augmente la puissance d'un serveur gratuit.
>>
>> je pense que les outils continueront de s'améliorer simplement
>> à la demande de leur utilisateur, en fonction des ressources dispo.
>>
>>> alors quehttps://moodwalkr.com/@montpellier/itineraire
>>> peut calculer un itinéraire
>> https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
>> j'espère que tu partageras mon avis que l'amélioration par
>> rapport à une représentation filaire ne saute pas aux yeux
>> alors que le point de départ et d'arrivée sont accessible
>> en ligne droite sans obstacle.
>> PS: je n'ai pas chercher à mettre l'outil en difficulté,
>> j'ai juste demandé la place et une adresse de la place.
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-18 Par sujet osm . sanspourriel 

Marc j'ai fait comme toi, écrit à peu près le même message et me suis
rendu compte avant de l'expédier que c'était l'ergonomie de l'outil et
non l'outil qui péchait.

Car là il te montre 4 trajets possibles : le plus court, le plus calme,
le plus touristique...

Il faut cliquer à Gauche sur le mode fin que tu souhaites pour qu'il
mette en évidence un seul des 4 trajets.

Jean-Yvon

Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ?

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


alors que https://moodwalkr.com/@montpellier/itineraire
peut calculer un itinéraire

https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
j'espère que tu partageras mon avis que l'amélioration par
rapport à une représentation filaire ne saute pas aux yeux
alors que le point de départ et d'arrivée sont accessible
en ligne droite sans obstacle.
PS: je n'ai pas chercher à mettre l'outil en difficulté,
j'ai juste demandé la place et une adresse de la place.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

2019-06-18 Par sujet marc marc 
Le 18.06.19 à 18:48, lenny.libre a écrit :
>> donc pour ma part, les routes donnant sur une place
>> se rejoignent en un point + souvent place=square
>> c'est une représentation imparfaite, mais c'est
>> à l'heure actuelle sans doute le meilleur compromis
> 
> Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ?

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.

> alors que https://moodwalkr.com/@montpellier/itineraire   
> peut calculer un itinéraire
https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
j'espère que tu partageras mon avis que l'amélioration par
rapport à une représentation filaire ne saute pas aux yeux
alors que le point de départ et d'arrivée sont accessible
en ligne droite sans obstacle.
PS: je n'ai pas chercher à mettre l'outil en difficulté,
j'ai juste demandé la place et une adresse de la place.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr