Bonsoir,
Je suis sorti un peu de mon 15ème pour un raid cartographique entre république et colonel Fabien.
Dans ce quatier j’observe que les trottoirs sont cartographier en area=yes highway=footway. ID n’est pas très content :
J’aurais donc tendance a aller plutôt vers area=yes highway=pedestrian
De façon général qu’elle est la bonne pratique qu’elles sont les bonnes pratiques si on souhaite « matérialiser » les trottoirs ?
Merci de votre aide.
Bonne soirée !
Djiril
si c’est vraiment du surfacique que tu souhaites, tu peux metre les deux attributs :
highway=pedestrianarea=yesPersonellement, les trottoirs c’est des ways de type sidewalk.
Je mets du surfacique éventuellement pour des aires larges (triangulaires ou à peu près carrées/rondes) mais pas pour un trottoir « un peu large ». Sauf peut-être pour l’avenue des Champs-Élysées.
Merci @Xandrex, effectivement dans certains quartiers je trouve que faire du « surfacique » fait sens quand il y a pas mal d’aires pietonnes car sinon je trouve que c’est difficile de décider quand s’arrête l’aire pietonne car il y a toujours un trottoir quelque part… Je ne sais pas si vous voyez ce que je veux dire…
Hello les gars,
Bonne pratique: FR:Bonnes pratiques - OpenStreetMap Wiki et son corollaire, on en taggue pas pour faire plaisir aux éditeurs et éviter qu’ils crient.
voici un exemple de règle :
si la zone fait plus de 10m de large, et qu’elle peut accueillir pendant une demi-heure un groupe de 60 personnes puisse faire une photo de groupe sans qu’il y ait d’obstacle entre le groupe et le photographe, ok.
Sinon, non.
Alors oui et non.
Quand on débute on ne connait pas toutes les compatibilités entre les différents tags. L’éditeur est là pour aider le contributeur débutant ou le guerrier distrait !
Si on ne peut pas faire confiance à l’éditeur pour alerter sur des incompatibilités, ça risque de devenir difficile de mapper correctement.
alors oui, il peut arriver qu’un éditeur ait des contrôles imparfaits, mais c’est l’exception qui concerne la règle, non ?
Tout à fait, mais remplacer le tag footway par pedestrian, c’est une mauvaise idée. Surtout que footway est complètement adapté pour mapper les trottoirs.
J’avais cru comprendre que pour le moment, la plupart des appli (toutes ?) n’arrivent pas à faire d’itinéraire à travers les zones ! Du coup, il fallait mettre un chemin piéton à travers la place (exception à la règle du «on ne cartographie pas pour le rendu»…).
Perso, pour les trottoirs proches (juste au bord de la route ou seulement séparés par du stationnement «on street», je met les info du trottoir sur le segment de route ; je ne sépare le trottoir que s’il y a une rangée d’arbres sur le bord du trottoir.
Tout dépend de la qualité choisie.
Sur Orange c’est les 2 mon général 
https://demo.openstreetmap.fr/map?profil=10&layers=653,37,layer;654,37,layer&pos=4.8176,44.1326,16
pedestrian ne doit être utiisé que si la surface permet physiquement aussi à des véhicules de circuler, donc largeur minimale de plusieurs metres, et puis de la longueur aussi, sinon c’est du footway.
Le problème c’est que seules les pedestrian sont rendu en surfacique (avec area=yes)… donc depuis déjà longtemps il y a une mauvaise pratique qui s’est installée à cause de ça et on abuse du pedestrian pour cette raison.
Il faudrait passer à… area:highway=footway mais ce n’est pas encore pris en compte par le rendu de base (mais en dev sur le rendu FR).
il y aurait donc un parallèle possible entre ça et les ponts ?
highway=* pour la voie (utile pour le routage)man_made=bridge pour le bâtihighway=footway pour la voie (utile pour le routage piéton)area:highway=footway en plus pour la surface?
C’est moi qui cartographie les trottoirs dans le quartier et oui : work in progress
D’autres mettent systématiquement des polygones (relations), je préfère les trottoirs « par rue » : sera mieux pour les associer à terme dans une relation rue (chaussée, trottoirs, n°) et j’en profite pour caler précisément les n°/entrées d’immeubles (survey + OpenDataParis).
Quant au choix pedestrian ou footway, c’est pour moi évident qu’il faut footway+sidewalk au vu du wiki et tant pis pour ID !
En lisant Key:area:highway - OpenStreetMap Wiki je ne comprends pas cela :
« area:highway=* had been proposed to describe the non-routable, detailed shape of a (typically linear) highway » donc OK pour une rue piétonne qu’il faut emrunter dans une direction (une voiture ne peut pas aller des façades impaires aux façades paires) mais
dans le cas d’un trottoir où un piéton peut aller dans le sens qu’il veut, où il veut, la phrase du wiki « area=yes on a highway=* describes a routable highway area on which the dedicated traffic can route omnidirectionally » me semble plus approprié pour les trottoirs et le futur routage piéton possible dessus (sortir du n° 5, jeter son mouchoir dans la poubelle, puis attendre à l’arrêt de bus après voir lu les affiches sur la colonne Morris;-)
C’est un peu le bazar en fait car les algo de routage prennent peu ou mal en compte les surface, qu’on les décrivent avec area:highway=* ou avec highway=* + area=yes
area:highway a l’avantage de bien séparer les descriptions surfaciques de celles linéraires, c’est plus propre que l’ajout de area=yes de mon point de vue et facilite la réutilisation des données.
Ensuite se pose la question du routage omnidirectionnel… vu que les algo classiques (plutôt conçus à l’origine pour les véhicules) sont très limités, soit on ajoute du filaire pour leur permettre différents routages, soit… on attend qu’ils évoluent.
Micro-mapping sans algo de micro-routage ça coince.
Je me suis posé la question plusieurs fois, et je pense que c’est utile d’avoir à minima du filaire highway=* ET EN PLUS une autre entité surfacique si nécessaire.
On peut bien sûr attendre les algorithmes de micro-routage, mais pour rendre plus accessible la données et son usage, c’est quand même bien pratique d’avoir une version totalement filaire facilement accessible.
Effectivement j’ai pu constater que JOSM signale que area=yes pour un highway =footway, est une anomalie et suggère la solution : area:highway=footway ,si on est attentif au message de validation.
Ce qui n’est pas possible, semble t’il , avec ID